Bitmapped Prim Type

Just a thought for a useful prim type - bitmap extrusion.

Convert a bitmap with transparent areas into an "extruded" 3D object. Bandwidth for this is as light as shipping any other bitmap. You could ship a 1 bit plane first to create the shape, and then ship the full bitmap to texture it.

So a picture of a wagon wheel becomes a wagon wheel, with the original texture automatically mapped onto front and back. (Allow changing the texture, but automatic mapping of the bitmap seems like an obvious win.) Allow the extruded edges to extend the texture map, or choose to turn off texture mapping there and have solid colored sides.

Extrusion can be flat cut (cookie-cutter) or rounded (puffy looking objects).

This could use bitmaps with an alpha plane, but it's probably sufficient to simply provide an x,y coordinate where the "transparent" pixel color can be found.


Probably the prim generation on the client side would employ a bit of curve fitting. The user could require "perfect masking" - where every pair of pixels on a boundary with a hole forms an extrusion area. But usually it'll look just as good to use a smaller number of extrusion rectangles to form the sides. Puffy extrusion could use up quite a few triangles, and would take more parameters to specify how puffy the extrusion is.

The front and back of the prim can just be rectangles of the same shape/size as the bitmap, with transparent areas made truly transparent.


Another variation - add high-relief height-mapping from bitmaps. Create extremely detailed and nicely curved objects, e.g. where bolts and flanges on a motorcycle engine stick out a bit. Using 8 bits per pixel of "bump height", you could make some truly complex objects - and still use one value (typically zero) to mean 'hole', as above. This might use the alpha channel of a bitmap, so that again you could automatically map the color planes as texture on the resulting shape.

This might slow down some older graphics cards though, if people started using a lot of this. Probably that can be limited by making one of these count as several prims when building.

Among other things, the height-mapping could be used to create very realistic face masks.

Bravo to this!

Yes, we've been begging for this since the dawn of time.
It belongs in the feature suggestion forum, though.
And you're not gonna get it

I think this would be uber complicated to implement in Havok.
And you're not gonna get it

Actually, it's already a "feature" in texture options for a prim - "Brightness" and "Darkness" pretty much does exactly that.

... but not very well. I, too, have been begging for this, and vertex baking, since the dawn of time. And I doubt we'll see it on the virtue that collisions would be a nightmare under Havok, as Strife points out.

Furthermore, BMP? JPEG-2000 all the way!

Thankfully, in the future we will probably get the ability to link phantom prims to physical prims, so we can have a 255 prim vehicle where the one physical prim is a transparent bounding sphere. But that will surely be after 1.7 which is supposedly the new Havok2 release date

Ooops - I meant to put it there - must have mis-aimed when I clicked through to this forum.

I can see the collision detection issue - but the phantom prim / bounding prim idea someone mentioned does seem to cover that. Hopefully someday.

Moved to feature suggestions for further discussion.

Jeffrey, the brightness and darkness options don't do anything at all like what Red is talking about with the wagon wheel, which is the main thing he's trying to say, so far as I can tell. The brightness and darkness functions aren't doing much of what he's describing in his variation either.

As far as I know, the "Brightness" and "Darkness" features generate a bump map based on the level of, well, brightness on a prim's textured face. The fact that this is not a very "good" bump map, that is - it doesn't work well enough to do what was described very well, was more or less my point.

Such is why I mentioned I'd kill for vertex baking.

not gonna happen

this kind of extruded mesh is extremely harsh on video cards (actually SL's terrain *IS* a height field projection from a stored image, and even just that one object, 256x256 per sim, takes a huge amount of rendering power (as anyone with a low end graphics card can tell you)

also these extruded objects tend to be rather useless for much other than actual terrain grids, what you are thinkin of is more of a 'mesh' object not an extrusion.. which is somethin thats already been discussed.. suffice to say the complexity involved in many areas is going to keep this from happening anytime soon (physics, client graphics, network performance, etc)