Smart Boxes and Pyarmids

[trepan]

I've made a patch for 2.0.8 that makes the "box" and "pyramid"
objects a little smarter. It will use meshes only if they use at least
one of the 2.0 properties (materials, phydrv, smoothbounce,
cumulative transforms, etc...)

As well, each side can be controlled individually:

Code: Select all

box
  notextures

  texture boxwall.png

  x+ texsize 1 2  # U and V scales
  y+ texsize 2 3
  x- texsize 3 4
  y- texsize 4 5
  z+ texsize 6 7
  z- texsize 7 8
  z- texture caution.png

  z+ passable
  
  x+ color red
  y+ color green
  x- color blue 
  y- color purple
  z+ color grey  
  z- color yellow
end

and for pyramids:

Code: Select all

pyramid
  notextures

  x+ texsize 1 2  # U and V scales
  y+ texsize 2 3
  x- texsize 3 4
  y- texsize 4 5
  bottom texsize 6 7

  x+ color red
  y+ color green
  x- color blue 
  y- color purple
  bottom color grey  
end

I'll release the patch once I've tested it a little more. Those wishing
to use it will have to compile from source. Note that this is a server-
side change, and that nothing need change on the client-side.

P.S. This should also provide a speedup vs. meshboxes and
meshpyrs. The new mesh boxes have 6 faces against the old 12,
and the new mesh pyramids have 5 faces instead of 8. The nice
part about these modifications (vs. a user defined group), is that
the texture coordinate will be scaled along with the object size if
the texsizes are negative (they default to -8.0). Note that this is true
for both the old style "size" keyword and the newer "scale" version.

[trepan]

I've committed the change to CVS (v2_0branch and HEAD).
As well as being able to specify texsize per face, you can
also specify texture coordinate offsets "texoffset u v".

Also note that as well as the (x+, x-, y+, y-, z+, z-) face
labels (no z+ for pyramids), there are a few extra keywords
to help you along:

box
top = z+
bottom = z-
sides = x+, x-, y+, y-
outside = x+, x-, y+, y- (meshbox keyword)

pyramid
bottom = z-
sides = x+, x-, y+, y-
edge = x+, x-, y+, y- (meshpyr keyword)

[A Meteorite]

So, this means that regular boxes will actually be faster than meshboxes if I use one 2.0 property?

[trepan]

It depends on your computer setup. The current
meshboxes and meshpyrs should already be faster
then the old style box and pyramids w.r.t. rendering
(they were significantly faster when I did my testing
on my old GeForce3). The new meshed boxes and
pyramids should be even faster.

They are a bit slower w.r.t. physics testing, but that's
insignificant if the collision octree is doing its job.

Some examples with my current Nvidia 6800GT.

Setup:
- 10,000 boxes (all in the view port)
- set _cullDepth 0
- no Radar, no Console, no HUD
- No Shaders
- No Shadows
- Fast Lighting
- Texture: lin-mip-lin, aniso = 16

Code: Select all

                 FPS    ms/F   tricount                                         
normal boxes:    15     61     118812
meshboxes:       16     56     319212
new mesh boxes:  18     51     239612 
grouped mesh:    124    0      240012

NOTE: the sceneNode/renderNode management is killing the FPS


Setup:
- Atlantis v1.4 (/roampos -800 -800 0 45)
- set _cullDepth 0
- no Radar, no Console, no HUD
- No Shaders
- No Shadows
- Fast Lighting
- Texture: lin-mip-lin, aniso = 16

Code: Select all

                 FPS                                                     
normal boxes:    107    
meshboxes:       146    
new mesh boxes:  176

[trepan]

Oops, forgot to turn off the Zpass on my client,
so in all those tests, everything was rendered
twice (no real advantage for the given setup).

Notice how using a well grouped mesh can
increase the rendering performance (~688.9%)
Although that 10000 box map is a contrived test
case, I've seen major improvements after having
converted a map to mesh format, and then done
spatial grouping.

[Dutchrai]

Best thing is the additional power over texture mapping. Right now I have some really stretched textures on some meshes

Great stuff! Can't wait to use this.