Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

New Prim Type: Grid

Olmy Seraph
Valued Member
Join date: 1 Nov 2004
Posts: 502
03-29-2005 12:10
Here's an idea for an alternative to having a big mess of prims to display a bunch of different textures as part of an object's UI.

Prim type: GRID

A grid would basically be a box prim with a special ability to segment the top side into multiple faces. Each face would be addressable with a unique face number. This would let you create a complex interface that where you could change small pieces independently, without having to create a prim for each piece.

If a 2D grid is too complex to implement, even a 1D segmenting would be good. In that case, I'd call it a SEGMENT prim.

You can create a small example of this right now by cutting a box to 0.375 and 0.875 - faces 5 and 6 are adjacent and perfectly flat. I'm asking for the ability to do this with an arbitrary number of faces (ok, perhaps max 256 faces per prim).
_____________________
Some people are like Slinkies... not really good for anything, but they sure bring a smile to your face when you push them down the stairs.
Cross Lament
Loose-brained Vixen
Join date: 20 Mar 2004
Posts: 1,115
03-29-2005 12:44
That is such a good idea, it scares me. :)
_____________________
- Making everyone's day just a little more surreal -

Teeple Linden: "OK, where did the tentacled thing go while I was playing with my face?"
Olmy Seraph
Valued Member
Join date: 1 Nov 2004
Posts: 502
03-29-2005 13:45
Oh yeah, combined with being able to detect which face was touched (/13/9a/38153/1.html), a grid prim could be used to create some seriously cool UIs!
_____________________
Some people are like Slinkies... not really good for anything, but they sure bring a smile to your face when you push them down the stairs.
Jeffrey Gomez
Cubed™
Join date: 11 Jun 2004
Posts: 3,522
03-29-2005 14:14
I've been considering scripting something like this using prims, as a tool... but I doubt that does much for you, considering it'd be more than one prim.

Anyway, I would love to see this or something similar. Really, I would. However, I seriously doubt the prim database is built to handle prim data that varies to this level of severity. Case in point, I know from scripting that it's very difficult for me to store a large body of texture parameters in one script buffer... and that's 16k (though, to be fair, it's in string form).

Honestly, I keep seeing things like this that, IMO, would just be solved if we had point editing by prims or more advanced NURBs support. Given I still see that as far off, I'm going to have to say that this is... probably not feasible in the short term.
_____________________
---