Page 1 of 4

null renderer

Posted: Wed Feb 21, 2007 5:22 am
by xyzzy
I've built a null renderer for ogre for my game project.
Why a null renderer? The server is the authority for the physics in my world. The clients (also using Ogre) are updated by the server. We're using OgreODE on the server to do the physics. It's useful to use Ogre to model the world because it's useful to be able to render and see what is happening on the server with regards to geometry and physics (and it's elegant to use same data structures on client and server). The null renderer is useful for running on the server without actually rendering the geometry and hopefully saving a few processor cycles. (haven't profiled it yet)

What is the best way to share? Can't seem to upload an attachment

Posted: Wed Feb 21, 2007 7:04 am
by syedhs
Sounds like a nice addition. But I am curious, we can just run physics without rendering right.. so what is the use of null renderer?

Posted: Wed Feb 21, 2007 7:20 am
by xyzzy
Our server uses ogre to model the geometry and ogreode to do the physics. We're using the scene graph, quaternion, etc. It's useful to be able to render the geometry on the server along with the physics debug geometry for visual debugging. It is also useful to not render the geometry on the server for performance reasons. I'm sure doing a physics only simulation on the server would be more optimal, but I'm not sure how much more optimal it would be. We do get good leverage by using ogre on the server.

Posted: Wed Feb 21, 2007 9:31 am
by Vectrex
I'd be interested in this. You can use something like http://www.quicksharing.com or http://www.filesend.net to host it. Or better still I think this could be put in the OgreAddons SVN as it gets asked for quite a bit.

Posted: Wed Feb 21, 2007 12:46 pm
by syedhs
Well sure there is a reason for null renderer, it is just me who cant figure out why :wink: If you are wiling to share the code, then probably you can ask Sinbad for an addon slot :)

Posted: Wed Feb 21, 2007 5:17 pm
by xyzzy
Vectrex wrote:I'd be interested in this. You can use something like http://www.quicksharing.com or http://www.filesend.net to host it. Or better still I think this could be put in the OgreAddons SVN as it gets asked for quite a bit.
Vectrex, thanks for the link. Here is a link to the null renderer source for now: http://s29.quicksharing.com/v/1204295/n ... r.zip.html

I have only tested with my project, so it is conceivable that some engine out there has a dependency on the renderer that I don't that hasn't been addressed. Also, I have only build in windows with VS2005

http://s29.quicksharing.com/v/1204295/n ... r.zip.html

Posted: Wed Feb 21, 2007 7:49 pm
by xavier
syedhs wrote:Well sure there is a reason for null renderer, it is just me who cant figure out why :wink: If you are wiling to share the code, then probably you can ask Sinbad for an addon slot :)
I also don't understand this every time it comes up. It always sounds like a bad design decision, tying the logic that closely to the rendering engine. But to each his own.

Posted: Wed Feb 21, 2007 8:24 pm
by Kojack
The usual use for a null renderer, at least whenever I've heard of one, is for profiling the performance of a library like Ogre without an underlying API or hardware affecting the results.

But server wise, it would mean Ogre is still doing various stuff like camera frustum culling, transparency sorting, skeleton animation etc, all of which are using cpu but producing no result when the null renderer is selected.

Posted: Thu Feb 22, 2007 12:45 am
by Praetor
I guess I'd say it is a toss-up with regard to design and such. Here we have Ogre with its own scene graph, well-maintained, storing the geometry for us and I can't help but think "why redo it in another part of the engine?" Just reusing what is already there seems sound from one OO perspective but then not so sound from others. Just remember any paradigm, design, or process is a means to and end. If it works for you, then great! Having a null renderer, maybe in OgreAddons certainly wouldn't hurt anything.

Posted: Thu Feb 22, 2007 1:26 am
by xavier
Praetor wrote:I guess I'd say it is a toss-up with regard to design and such. Here we have Ogre with its own scene graph, well-maintained, storing the geometry for us and I can't help but think "why redo it in another part of the engine?" Just reusing what is already there seems sound from one OO perspective but then not so sound from others. Just remember any paradigm, design, or process is a means to and end. If it works for you, then great! Having a null renderer, maybe in OgreAddons certainly wouldn't hurt anything.
Your physics library already does it in another part of the engine -- it manages its own scene graph optimized for collision detection, so that argument doesn't hold. The scene graphs maintained by each bit of code are optimized for their own purposes -- Ogre's is optimized for graphics, and it very well might not be the best choice for your application's logical object structure. For example, what do you do when you need to process distant objects in your logic that you might have removed from the graphics rendering scene graph? (could have had their Entity unloaded, and so on).

It's not a good design to try to use these bits for purposes for which they were not designed. And as Kojack said, math libraries are math libraries, whether you roll your own specific to your needs or use a premade one. There is nothing magic about Ogre's math libraries.

Posted: Thu Feb 22, 2007 6:09 am
by xavier
Interesting thread in the sweng-gamedev mailing list recently somewhat related to this topic -- strongly recommended read for everyone interested in the topic of using the graphics renderer for non-graphics purposes:

http://lists.midnightryder.com/pipermai ... 06289.html

Lots of good food for thought in there.

For the record, I am in the "separate physics completely from rendering" camp.

Posted: Thu Feb 22, 2007 7:14 am
by xyzzy
Well, I did consider both approaches. And, perhaps some day, if server load becomes a big enough problem for our system, we'll either stub out more and more of the rendering code in Ogre for the server, or we'll redesign the server from scratch to be more efficient. We are planning on using the PLSM plugin for Ogre to do large scale terrain. It seemed more effective to leverage the existing PLSM code on the server and client than to write it again for the server.

Posted: Fri Feb 23, 2007 1:40 am
by tau
I always was asking myself: how do I do a networked physics camera culling and not sending physical objects update which are behind the camera (very wasteful to send all the objects in the scenegraph over the wire)...
Seems like reusing ogre scenegraph is a good decision to me... that way, in a networked game, camera always can be adjusted by the server side to avoid unfair gameplay (looking through the wall, etc...).
Am I wrong?

It seems like Strategy and/or Observer Paterns may help to solve this thing by decoupling physics and rendering code from each other, but letting them work together...

Posted: Fri Feb 23, 2007 1:44 am
by xavier
You do collision with the camera as well. There is an article on one approach in GPG4.

Posted: Fri Feb 23, 2007 5:52 am
by Kojack
how do I do a networked physics camera culling and not sending physical objects update which are behind the camera
Depends on the type of game. The Quake family has the camera direction controlled purely client side. While players can put up with a bit of movement lag, having camera lag is unacceptable in anything requiring precise aiming. With a quick mouse movement, the player can see behind themselves before the server can realise and send the updates for objects which were previously out of sight.

Culling local physics is probably best done by position (like which room you are in) rather than direction.

Posted: Fri Feb 23, 2007 1:07 pm
by Kencho
In any case, I'm quite interested in this at this moment. It's nice to have something rendered in my project (as it's a single player game), but I find it ugly when it comes to unit testing. A window popping up and closing intermitently is quite annoying during unit and regression tests... A null renderer sounds like a good feature for these tasks :)

Posted: Sun Feb 25, 2007 5:27 am
by Kartweel
Cheers for posting that. Comes in very handy every now and then when you don't want a render window and don't want to spend a lot of time removing ogre from everywhere. Will have to work on a multi-platform version.

Posted: Sun Feb 25, 2007 5:46 am
by Game_Ender
Actually a null renderer is the perfect tool for unit testing. If it becomes cross platform I think it should become and addon to the core set of plugins or an official ogre addon.

Posted: Thu Jul 05, 2007 6:27 pm
by rewb0rn
Hey, just downloaded the nullrenderer, but unfortunately it seems to be for ogre dagon. Got some compile errors complaining about abstract functions, that I guess have been added to eihort. I just added them to the renderer classes without any functionality. it compiles but throws an exception when trying to initialize all ressources, so I think there is more work to upgrade it to eihort. Has anyone already done it?

Back to the server topic, because thats why I want to use the null renderer: You say you use a physic library without having ogre included on the serverside. My problem is that I use OgreOde, and that is really Ogre dependent, and I am not going to rework all my classes so that they a) parse Ogre Mesh files on their own and b) use ode instead of OgreOde. Would be really nice to have the game logic completely independent from Ogre, but that is just to much work to do for me. In addition, how would I be able to access animation data then? Because my game requires to check for collision with fists etc. and that of course on server side, too. Is there a solution I just dont see or is it really that much work?

Posted: Fri Jul 06, 2007 8:07 pm
by rewb0rn
I ported the null renderer to ogre eihort now. if anyone is interested, pls let me know. I would still appreciate opinions on how to use ogreode for a server sided physics simulation without a null renderer.

Posted: Sat Jul 07, 2007 11:45 am
by Kartweel
Can you put a link to download the updated nullrenderer code somewhere?

Cheers,

Ryan

Posted: Mon Jul 09, 2007 2:09 pm
by rewb0rn
http://s7.quicksharing.com/v/7629141/Nu ... r.zip.html

There is one very strange bug: the release version crashes if there is a cegui call to set a text, the application only crashes if release version is started by a double click on the exe file, not if i start it via visual c++. i have no idea what could be the reason, but because i dont expect a gui to be on the server i ignore it for now. (have no idea how to debug this with adequate effort)

please tell me if you experience that bug, too.

Posted: Wed Oct 10, 2007 1:19 pm
by Vectrex
rewb0rn wrote:http://s7.quicksharing.com/v/7629141/Nu ... r.zip.html

There is one very strange bug: the release version crashes if there is a cegui call to set a text, the application only crashes if release version is started by a double click on the exe file, not if i start it via visual c++. i have no idea what could be the reason, but because i dont expect a gui to be on the server i ignore it for now. (have no idea how to debug this with adequate effort)

please tell me if you experience that bug, too.
Hi can this link be refreshed? I'm doing some network testing and a null renderer would come in very handly to test loads of clients without changing any logic or popping up windows.
Does it work with the latest Ogre?
ps I think this really should go in OgreAddons despite Xavier's advice ;) I do agree that using ogre on the server isn't so good, but you can just use Ogre's 'stuff' without actually starting ogre too.

Posted: Tue Oct 30, 2007 3:53 pm
by SpaceDude
The link doesn't work anymore :( I know the topic is quite old. Does anybody still have the source code? Maybe it should be made into a wiki article if its not so big rather than uploading to temporary file servers every couple of months :)

I am also interested in using this as a quick-n-dirty way to get a dedicated server up and running. I can see why in an ideal world it would be good to separate physics from rendering completely. But as a few people have mentioned before this can be difficult. I am using AGEIA's PhysX to deal with the physics, and there a few reasons why it can't run separately from ogre without a lot of work:

- I am using Ogre's mesh file format to load in objects, once loaded by ogre I then transfer the mesh to PhysX for collision detection. Clearly I don't want to write my own code to read mesh files without depending on Ogre.

- Some collision detection is based on skeletal animations. e.g. there is an animation of the player slashing with a sword, the collision detection is approximated by an oriented bounding box encapsulating the position of the sword between two consecutive frames. In order to do this without Ogre, I need to read the mesh file and animations file and basically re-code the skeletal animation system. Obviously not a good idea.

In terms of CPU, you can avoid ever calling renderOneFrame by using a custom game loop. This means that you avoid all the stuff mentioned by Kojack:
Kojack wrote:But server wise, it would mean Ogre is still doing various stuff like camera frustum culling, transparency sorting, skeleton animation etc, all of which are using cpu but producing no result when the null renderer is selected.

Posted: Tue Oct 30, 2007 5:03 pm
by Vectrex
Ah, I found the old version.
http://users.on.net/~edan/cam/Ogre/
I'd be interested to see how much it needs to get working now.