New prim type: variable face

I was thinking about this today, and I'm thinking it might be nice to have a "variable face" prim type.

This would give us a much easier way to adjust our prims and build things. It can be very difficult to find just the right mix of cut, shear, size, and scale to get a part looking the way I want it. If we could just grab the corners of boxes and drag them around, it would be a lot easier to get things looking the way we want.

I can think of many shapes that the cube could be deformed to that we can't currently do with the parameters we have. Allowing us to drag the verteces directly will make things easier and faster for ALL builders.

I have crunched some numbers, and it looks to me like it's possible to do this without really adding any data-transfer overhead, especially if a certain form of compression is used.(You chop off unneeded leading bits, concatenate the whole bitstream, and then reverse that process at the client side.)

Can the Havok physics engine handle the shapes this would produce without too much of a performance penalty?

A long time ago, one of the LL developers posted in here that arbitrary concave objects are somewhat tricky on the physics. I don't know if that is still true with today's tech (this was about a year ago) or how it would work with Havok 2. I previously suggested a concept called parametric deformation modelling that is kind of like this. It compresses insanely well, as demonstrated by Farb-Rausch in their 64KB intros (poemtoahorse etc.)

Since the physics engine already sucks to high heaven, it can't be any worse....

I tried to make a boat last night, and no matter what i did, I couldn't make the darn thing float in the river. I finally just gave up and made it a non-physical object.

Since the physics engine already sucks to high heaven, it can't be any worse....

I tried to make a boat last night, and no matter what i did, I couldn't make the darn thing float in the river. I finally just gave up and made it a non-physical object.

To make a boat - you have to make it a vehicle and then make it the type balloon. You can then change its parameters so that it will only hover over water, then give it a negative hover height.

Sled also works. Car should as well. The vehicle system won't work on really huge things, so if the boat was as big as a house it wouldn't have worked.

our video cards are programmed to render the opengl shapes and parameters quickly and correctly.

we keep them very busy by adding terrain & av meshes as well as dozens of custom textures at a time.

if we start introducing shapes that they have to vector and mesh from scratch, we'll never see anything. maybe when video cards have a few coprocessors to handle varying functions this type of thing will be possible.

Khamon has a point there. Maybe someday if LL figures out a way to do BSP or some other really efficient kind of occlusion culling, it'll be feasible on a large scale (and that is what SL is.) The viewer is already beating the tar out of your CPU and video card, trying to push literally thousands of textures in some scenes, all the while suffering from the huge amount of overdraw necessitated by the current state of the engine.

It is my understanding that the prims we are given are actually inherent to OpenGL, which would imply that there is some kind of optimized code path for drawing then directly in the firmware on our GPUs.

One time I was playing Doom III and I went into noclip and flew off the map, so I could get a bird's eye view of the level I was trying to pass. Once you are outside the level, the engine can't take advantage of the vis data stored with the BSP tree, and it has to render everything within your frustum, just like SL has to all the time. It went at a very low FPS, about the same as I'd expect SL to push with a similar amount of geometry with local lighting turned on.