Working on a game...

[mirv]

Still working on those darned boxes. I've decided to have physics being heavily integrated into the engine - I have the theory that physics hardware can deal with the extra calculations. I think that rather than using such hardware for lots of particles, etc, I'd rather have more user interaction with a scene - for example, in a forest, I'd like to be able to shoot branches down and stuff.
Anyway, when I work on things, I'll keep the updated here.

[The_Hard_Mission_Guy]

What do you mean with heavily integrating physics in your engine?
do you mean that you are starting your own physics simulation or are you still using bullet that you mentioned in a previous post?

anyway , the idea of moving the physics to a specialized hardware is a great idea as you suggested !
it would allow because of the higher processing capabilities , much more detailed simulation ......like you would be probaply able of simulating a model(like a tree or car ,etc...) as many smaller models , you would have a group of tiny models which are processed independently that together form up the bigger one(car,human,tree,etc...)

and then if the car for example crashes the individual smaller pieces of the car would fall apart or even deform like in a real accident!

As someone said : imagination rules the world!

[mirv]

Quality rather than quantity. Stuff like grass moving as you pass by, blowing bits off a car and using it, etc etc etc.
Of course, dealing with collisions and physics is one thing, what to do with it all once you know it's collided is another! But I figure with the extra cpu cycles saved on physics, that kind of thing can be taken care of.

[The_Hard_Mission_Guy]

Anyways , you are the Expert when it comes to Graphic Engines...
I think the extra cpu cycles saved after implementing hardware acceleration for physics could be employed best for some kick-ass AI

[mirv]

In Germany, and will be getting back up to work on the engine again soon (kudos to Nova for my beast of a machine, and nice monitor, both of which I will find very nice for programming).
Anyway: question for A.I guys - would it be useful to have a way of quickly determining what dynamic and / or static objects are close to a character? I'm thinking of making an octree with one object per node for things like that - I figure it would be useful in visibility culling, but is kind of overkill for that, and might take time to sort it and keep it "nice", but if it would help for a.i then it would be worth it!

-- Ignore this, I was tired.

[mirv]

Just letting folks know I haven't stopped working on things - I'm getting back into it any day now, once I have my spatial storage method sorted out in my head.

[mirv]

Small news update (nobody minds me giving one I hope) - spatial tree is starting to stand. Memory footprint is about 3.7MB for handling 50,000 objects (400kB less for 32bit systems), however it doesn't handle dynamic memory too great - set the tree at startup, and don't put in more than it can handle basically. Startup for that many takes some time (12 or 13s, but that's including some texture loading) - so dynamically moving 50,000 objects in & around the tree may need some work.
Anyone know that if, in theory, replacing ~21 +/- operations with one square root and a couple of +/- operations is better? I've had it drilled into me so much to avoid square root functions that maybe I'm over-compensating.
edit -- it's not better, it's much slower.
edit2 -- no, I was wrong! turns out constraints on node spatial size were causing an unbalanced tree. Different algorithm using square roots allows tighter constraints and (I think...) a better tree, resulting in a load time of about 2s now.

[Rick]

edit2 -- no, I was wrong! turns out constraints on node spatial size were causing an unbalanced tree. Different algorithm using square roots allows tighter constraints and (I think...) a better tree, resulting in a load time of about 2s now.

Cool
Don't hesitate on screenies ...

[mirv]

I won't when there's something more interesting than 50,000 grey boxes on the screen. Still working on my spatial tree - it's a rotten bugger to get balanced, though (I think and hope...) once balanced it's easier to keep that way due to locality of movement. So I'm focusing on repairing it when it's out of whack (aka rebuilding below a given node).
Good news is that it doesn't just apply to visibility culling, but overall determination of nearby "stuff" should be simple - and that is of value to many aspects of a game engine I believe (a.i, physics, rendering).
Back to it...

[mirv]

Another update: my visibility tree is coming along very nicely. I just finished some code to rebuild the tree when unbalanced (only to be done when there's free time), which works just fine (near as I can tell). And a balanced tree improved my test bed framerates substantially for viewing only smaller areas - though as expected it was a tad slower if I tried to view everything at once.
Now to stress test the new "balancing" code and see where it breaks, and more of the fun that is debugging.