Quote:Original post by cpiasminc
I fail to see how this disputes that recursion is bad performance-wise.

First of all, traversing a KD tree doesn't need recursion. It can be done iteratively by pushing the far node to a stack if it needs to be traversed later. Havran's PhD thesis demonstrates the algorithm very simply.

Second, accessing memory randomly is a far greater expense than the cost of recursion. An L2 cache miss is about 500 cycles, while setting up a stack frame and branching is like 30 (since the stack is almost never an L2 miss). The real enemy is memory latency in every case. There are no 'bad algorithms' just 'bad implementations'.

For instance, an enterprising PS3 developer might break his KD tree into self-contained 4kb pages that can be prefetched to the SPE, and the entire tree traversed with almost zero latency penalty. Next Gen Engine design is all about algorithms that employ predictable fixed-footprint memory access with very minimal indirection.

Quote:Original post by Wavesonics
I'd LOVE to get Carmack’s input on this topic since he has been one of the driving forces behind many of the engine techniques the industry has used

While there will continue to be new engines, just like there are new programming languages and off-line renderers, there is going to be much less of a pressing need for them. Some people will still do it because some people like making new things like that. But the chances of it becoming a landmark event for a broader, industrial scale, I think, are less likely.

- John Carmack

I was just going over a design on paper for all the main parts of the engine, i want to share some of the basics here so to get a bigger discussion going and maybe try and get some help and have other people learn something too ;)

I am not looking much at implementation details here, just design in an oop uml style way.

First off, most games now have a multiplayer support and this can be commonly over a client/server model.

There is normaly a scene manager class which deals with space partitioning and culling and also collision etc, although the physics one may be in a different tree like structure.

I was thinking of having all entities that are loaded stored in a vector and then have each of the trees reference them through pointers.

Just noticed that OGRE has position/rotation info of the entity stored in a scene node object that is attached to the tree and references the entity object which just has the mesh data etc. This to me seems a bit odd as If you wanted to incorporate physics then position and orientation should be shared and would be best stored in a the entity class?

Now the way I was thinking of it was the scene manager finds all objects visible and sends thier transform, material info and vertices to the renderer, and the renderer will deal with batching, changing render states etc etc. so an entity will never have draw style calls in it, though the scene manager might be able to tell the renderer to change states?

I will leave that part just now as obviously I dont have a lot of knowledge, what would your ideas be?

one other important thing i wanted to add here, is game logic.
Now I have a game state manager which is responsible for changing from say menu to running or paused etc. each just has init and update functions in them and they are implemented in scripts. They are responsible for setting up gui for menu and loading basic engine realted resources. However I am seeing less need for this class now as it was being used to control the game logic and i am not sure if thats a great idea. e.g it was checking if the arrow key was pressed then updating the players position.

Now i was thinking that each entity can have a script file with a list of behaviours in it, and if player is an entity it might be best cheking input in here? Also NPC AI functions could be in this script aswell as trigger functions for changing level etc, thought?

Finally, all of these would be dispatching messages so they can be processed and sent over the network if need be.
So say the input manager sent a message saying that the left key was pressed (or would it be best for it just to save states and the player script just check a state?)
and so when the player entity got it, it generated a player move message and dispatched that to the engine to process (would it be best for player to update position or just send the old position, direction and velocity to the scene manager?).

Basically how should these sort of messages be generated and processed? I know not one way is correct but the goal here is to try and make each class not have to rely or know much about other classes. So my entity could just create the message and attach data send it to my engines main event handler and let that filter it all the way down to who needs it and let that class deal with it.

I.m gonna leave that just now as my post got way too long lol, i'm gonna try and come up with some better designs for this thing.

Look forward to more replys.

Quote:Original post by VladR

Quote:Original post by zedzeek
you want a peak at the future, check out
http://www.naughtydog.com/comingsoon/index.html

There was a higher quality version of this trailer some time ago. Maybe GameTrailers ?

This maybe? Seems roughly the same quality though.

Quote:Original post by VladR

Quote:Original post by zedzeek
claimed to be actual game footage

Of course this is in-game footage, it would be a weak render anyway. Environment has average amount of polys (I`m sure PS3 can handle more complex scenes, but they haven`t had enough time yet to accommodate for well-known reasons, so we`ll see much nicer stuff in 2-3 yrs time). Very nice textures there and animations are simply beatiful, almost seamless, still interpolation is visible, but not that much as in Gears Of War. What we don`t know is that how many of these animations are simply prescripted for the sake of the trailer, and how many are going to be actually context-sensitive.

Agree. I think that one basic thing that is going to be an important factor in the future is simple ([smile]) high-frequency detail. For most applications (micro-albedo, HF normals, etc), procedural creation of HFD seems reasonably easy. I imagine that most of us will be generating HFD almost entirely implemented within procedural shaders in the coming few generations of video cards (and in 360/PS3 as development matures).

Quote:Original post by VladR
Which leads me to the point: It`s the art that drives the next-gen, not the engine/effects itself.

High-five!

I think that with expenses skyrocketing, procedural content (at every scope) will be getting far more emphasis than it has in the past. This can apply to nearly everything - though I figure that characters will remain largely in the artist's domain for a while still. Though... NaturalMotion is showing us just how much assistance we can give to the artists already [smile].