I still do not see why you need 500 cubes as instances. At some point I can imagine you lock cubes, they can be part of a "userworld" mesh. You also could run simulations and apply the force to a series of vertices only, as you know that a cube would be a series of 24 indices into mesh subgeometry. A cube can be then represented in your code as a single indice for instance.
Fabrice On May 2, 2011, at 1:46 AM, Trent Sterling wrote: > My game involves letting users create their own levels from cubes. The > physics engine allows for 500 or so stacked boxes without too much of > a performance hit. My bottleneck is rendering. > > On May 1, 6:40 pm, Fabrice3D <[email protected]> wrote: >> Why would you have that many cubes? You could simply arrange in larger >> meshes with your cubes data and extract when you need to edit or alter one. >> If you need that many because of the images on them, think in term of >> mapping.. >> >> Fabrice >> >> On May 2, 2011, at 1:08, Trent Sterling <[email protected]> wrote: >> >> >> >> >> >> >> >>> I'm another broomstick user who wants to create a few thousand cubes >>> in a scene. Using clone helped a lot, but the performance is still >>> very poor. Loading a single model with 80,000 polys is much smoother >>> than making many cubes with the same amount of polygons showing. I run >>> other molehill demos without issue, am using wmode direct, and my card >>> is supported. Hope to see a solution soon :\ >> >>> On May 1, 5:13 pm, rjgtav <[email protected]> wrote: >>>> Followed the instructions in this >>>> site:http://www.google.pt/url?sa=t&source=web&cd=1&ved=0CBgQFjAA&url=http%... >> >>>> And yes, my graphics card is supported. The 2nd values are around 300. Btw, >>>> i think i've forgot to mention, but all of the molehill examples work fine >>>> for me. But for some reason my framerate drops down by half when the camera >>>> is pointing to all the squares.
