null renderer

[SpaceDude]

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.

Thanks Vectrex, I'll let you know how much work it takes. And post an updated version somewhere if I get it working.

[Vectrex]

Just tried a quick compile and didn't get much so that's good.
'NULLTextureManager' : cannot instantiate abstract
'NULLRenderSystem' : cannot instantiate abstract

[SpaceDude]

Well I've managed to get it to compile but I'm having some trouble with it.

I get a crash in "OgreTexture.cpp" on line 282:

Code: Select all

{
	// Print data about first destination surface
	HardwarePixelBufferSharedPtr buf = getBuffer(0, 0); 
	str << " Internal format is " << PixelUtil::getFormatName(buf->getFormat()) << 
	"," << buf->getWidth() << "x" << buf->getHeight() << "x" << buf->getDepth() << ".";
}

The problem is that HardwarePixelBufferSharedPtr is NULL.

[SpaceDude]

Well I kinda managed to do what I want by just never rendering any frames and hiding the render window... Its a quick and dirty hack for the time being until I come up with a better solution. Does anybody know if this is likely to cause problems on server-only machines that perhaps don't have d3d or opengl support? I guess this is where having the null renderer comes in handy.

[Game_Ender]

Is this for a unit testing setting? I would think having a NULL render system would really improve the speeds of the tests. I might be speaking to soon though.

[JamesKilton]

For Ogre.rb tests, I ended up just finding out the minimal required initialization, which includes opening a window, and keeping Ogre initialized through the tests.

This means that tests need to clean up after themselves in certain cases, but I'm ok with that. For the record, here's the minimum required setup (in Ruby, of course):

Code: Select all

	def setup
		@@root ||= nil
		unless @@root
			@@log_manager = LogManager.new
			@@log_manager.create_log("Test.log",true,false,false)

			dir = File.expand_path( File.dirname(__FILE__) )
			@@root = Root.new "#{dir}/plugins.cfg", "#{dir}/ogre.cfg", "Test.log"
			@@scene_manager = @@root.create_scene_manager(ST_GENERIC, "test")

			renderers = @@root.get_available_renderers
			@@root.set_render_system(renderers[0])

			@@root.initialise(false)

			@@window = @@root.create_render_window("Testing Ogre", 320, 240, false)
		   ResourceGroupManager.instance.initialise_all_resource_groups
		end
	end

[SpaceDude]

Yeah that's pretty much what I did... And Game_Ender, no this is not for unit tests but for a dedicated server that doesn't require rendering.

[Tiser]

Sorry for resuscitating this old thread but I figured that it would be better to elaborate here since most of the reasons have been explained already in this thread.

I just want to say that there's a real need for a null renderer. In my project the server needs to be terrain and meshes aware (we have a collaborative terrain and scene editor, so the server needs to be able to read all the resources and perform operations, check for collisions, etc). It's much easier to use Ogre for that purpose than reimplementing the terrain and meshes loading functionality and all the necessary geometry helpers. We are talking about 30 minutes of work Vs. 1 month of work plus having to mantain it as Ogre3d evolves on the client side... So please, don't tell me this is "bad design", because redoing all that would be plain crazy. The idea that we shouldn't do this because Ogre is a renderer engine is flawed IMHO. Sure, rendering is Ogre's *primary function*, but that doesn't mean you can't use it for other things. For me, Ogre is a rendering-oriented geometry engine. Since I need a geometry engine on the server side, using Ogre there too is the smart solution.

So currently we have the dedicated server running on xvfb (a virtual x server) with mesa3d, we create a little window in it and we don't render to it, which is very ugly, complicates server deployment, increases RAM usage and the chances of a crash. But it's the best solution we have currently, cause it just works and it saves us from having to implement a lot of stuff in the server... but it's very unfortunate that we have to do this when it would be really easy to do a null renderer.

And I read somebody answer to this: "just get a GPU on the server". That won't do. First, you still need an X server for no reason and second having custom hardware in your dedicated is not economically feasible because that forces you to hire custom housing services that are 10 times more expensive that normal dedicated hosting. Also you can't access hardware 3d acceleration in a virtualized (hypervisor) environment and we really need virtualization for financial and security reasons. (I know there's a project to get acceleration inside xen, etc but it's very unstable)...

I'm not the first person that is being forced to use xvfb to simulate a null renderer (In fact I got the idea from another guy on these forums) and we will keep on using it, because doing it other way is just unfeasible, so the need exists.

So, considering that a NullRenderSystem would be just a bunch of stubs, would you guys reconsider? It doesn't add much to the work of mantaining the project and it would be a much welcome feature for many people. I could do it myself, but it would be pretty pointless if the Ogre guys aren't going to put it on the trunk and mantain it as the rendersystem interface evolves. I don't think I should even do it though, since a Ogre expert could probably do it 10x faster and with less potential bugs, but I don't mind to contribute this code if you guys want it and want to mantain it, otherwise I'll keep using my hack.

PS: A NullRenderSystem is also very useful for Unit Testing!

[xavier]

It's much easier to use Ogre for that purpose than reimplementing the terrain and meshes loading functionality and all the necessary geometry helpers

In other words, you painted yourself into a corner with an incorrect design decision a long time ago and now you want someone to bail you out?

So, considering that a NullRenderSystem would be just a bunch of stubs

This could not be further from the truth.

The project I am working on at present was designed from the start to run the same update code with no renderer on the server. When it came time to get the server going, it took about 5 minutes for me to disable where the renderer was initialized and shutdown, and the server runs "headless" without a hitch. This is because I designed my resource handling around this exact need -- the same issue you are facing. You unfortunately tied your update code tightly to rendering resources. What you should have done long ago was take the time either to create your own resource format(s) -- you could easily have serialized Ogre's to and from the editing portion for use on the server backend -- and had your update code deal only with the data it needed, rather than inextricably intertwining Ogre like it appears you have.

Sorry, I for one don't have any more sympathy for these same exact bad design decisions that come up time and again. And I can say for certain that Sinbad has far more important things on his plate than this.

That said, you say it would be easy to do a null renderer -- by all means create one and submit it either as a patch or addon.

[volca]

We needed this thing as well. For us, it is the need of usage of ogre's resource system (only) without graphics (for command line utilities for example) - automatically registered script parsers cause segmentation fault somewhere inside ogre if render system was not yet initialized (which seems as a bug to me) - maybe the correct solution to this problem is to patch ogre to wait with the loading to until render system is initialized though.

Anyway we have a the null renderer compilable against Ogre 1.6 in the SVN here - look into trunk/thirdparty/. It does not yet work for me as I need to provide pixel buffer support which is missing in the xyzzy's implementation. Feel free to submit patches

Edit: But I still agree with xavier that it is a bad idea to use ogre as a server side thing. Problems usually seem to source from the fact Resource System seems usable to do non-graphics tasks - in this area I'm torn apart a bit, because it seems logical that the system could be used without graphics (but I'm not talking about loading meshes and materials here) as it does not depend on it, it is the other way round...

[xavier]

We needed this thing as well. For us, it is the need of usage of ogre's resource system (only) without graphics (for command line utilities for example) - automatically registered script parsers cause segmentation fault somewhere inside ogre if render system was not yet initialized (which seems as a bug to me)

It's not a bug -- anything that creates something that needs a renderer resource (textures) needs to know about the render system specifics that the resources are being created for.

[volca]

I meant the segmentation fault - maybe an exception should be prefered? I understand the library can't be prepared for any kind of misuse imaginable though.

[_tommo_]

Maybe, the fastest solution would be to let ogre work without actually requiring a window or a primary render target... as i don't see why resources, terrain, and other features should require Ogre to be rendering at all...

[Tiser]

In other words, you painted yourself into a corner with an incorrect design decision a long time ago and now you want someone to bail you out?

That's why I don't participate on forums much. On what do you base yourself to make that kind of accusation? Do you accuse people of sloppiness everytime they do something you don't agree with? I designed it like this from the start. I knew what I'd get and I'm happy with it, in that it was the best solution for the time invested. I have a functioning, stable server that runs perfectly and I set up a prototype in a day If I was to do it like you suggest it would have taken me much, much longer, so from my point of view (some of us have harsher time constraints than others) your decision is the incorrect one. But you won't read me calling you irresponsible or sloppy as you seem to imply just because I disagree with you, obviously we just have different priorities.

The point of my post was saying: hey, maybe it's time for the Ogre guys to add a Null Renderer. What I would gain from it is simplifying my deployment process, there's no corner to get out of as you like to fantasize. (And I know I'm not the only one that wants/uses a nullrenderer). If I had to start my project again I would repeat my current hack because it works very well, so the need is there.

Anyway we have a the null renderer compilable against Ogre 1.6 in the SVN here - look into trunk/thirdparty/. It does not yet work for me as I need to provide pixel buffer support which is missing in the xyzzy's implementation. Feel free to submit patches

Thanks a lot, I'll try to use that with the SVN version of Ogre I'm using.

Maybe, the fastest solution would be to let ogre work without actually requiring a window or a primary render target... as i don't see why resources, terrain, and other features should require Ogre to be rendering at all...

That would be the most logical design from my point of view but it's my understanding that it's currently like that due to technical reasons so I doubt this will be changed.

[volca]

The reason for that is there is a tight coupling between data loaders and render system - that is hardware buffers used to store the loaded data.

I can see the point where xavier is standing - Ogre is "Rendering only" library. I also can see the point where you are standing - you need meshes and skeletal animation to do server side collision detection, for example (which can sure be done more cleanly using physics library, but you still need the mesh loaded to get to triangle data). I think this is a collision between clean and practical

[Vectrex]

Perhaps thought should be put into Ogre v2.0 about modularising some bits more. This has come up before about making an 'OgreToolbox' type thing. Since resource loading isn't exactly rendering it's common for people to have their own resource stuff etc. Ogre is obvious nicely modular now and I haven't tried doing this, but by the sounds of it, it seems non-trivial to use some non-rendering parts in isolation.

"The reason for that is there is a tight coupling between data loaders and render system - that is hardware buffers used to store the loaded data."
yes but ogre can operate on the loaded data. It doesn't need to tie the two together. Just like it uses a seperated lib to load textures.

[Praetor]

There is already abstraction for the loaded data. Separating the loaded data even more puts another layer into the system. You would have loaded data which would then need to actually be loaded into hardware buffers. Finishing a null renderer would be welcome but for us that would be low on our priorities. There's a lot of work to do that involves actually rendering, which is the point of Ogre, after all.

[Tiser]

Finishing a null renderer would be welcome but for us that would be low on our priorities. There's a lot of work to do that involves actually rendering, which is the point of Ogre, after all.

I understand that, and from my point of view the problem is not doing it as much as mantaining it, updating it and testing it in every new version... So, you say it would be welcome, does that mean that if somebody finished the null renderer linked above, would you guys add it to the trunk and go through the trouble of keeping it updated? i.e: official "support". Is there enough interest inside the team? That's all I want to know.

PS: Just noticed that both Irrlicht and Crystalspace have null renderers (The fact that others do it doesn't mean a thing, I'm just saying, it would be nice for people coming from those engines also.)

[xavier]

In other words, you painted yourself into a corner with an incorrect design decision a long time ago and now you want someone to bail you out?

That's why I don't participate on forums much. On what do you base yourself to make that kind of accusation?

Your description of your reason for wanting a null renderer.

Sorry if I come off harsh -- it's annoying when someone posts "don't call this bad design" when it clearly is exactly that. You could have avoided this long ago -- as is most often the case, software problems are cheaper to fix during design than after completion.

[DanielSefton]

I've got on fine without a null renderer; just create a simplified version of Ogre::Root on the server, create an instance of DefaultHardwareBufferManager and hey presto. I'm able to access stuff like MeshManager, MaterialManager, ResourceGroupManager etc. no problem.

I don't see what the fuss is about.

[xavier]

PS: Just noticed that both Irrlicht and Crystalspace have null renderers (The fact that others do it doesn't mean a thing, I'm just saying, it would be nice for people coming from those engines also.)

That's because both of them have software renderers -- Ogre is 100% hardware-accelerated.

[xavier]

I've got on fine without a null renderer; just create a simplified version of Ogre::Root on the server, create an instance of DefaultHardwareBufferManager and hey presto. I'm able to access stuff like MeshManager, MaterialManager, ResourceGroupManager etc. no problem.

I don't see what the fuss is about.

Try to create/load a texture without initializing a render system.

[DanielSefton]

Try to create/load a texture without initializing a render system.

Why would you want to do that on a server?

[xavier]

Try to create/load a texture without initializing a render system.

Why would you want to do that on a server?

My point exactly -- it's part of the whole reason this thread got resurrected.

[Praetor]

So, you say it would be welcome, does that mean that if somebody finished the null renderer linked above, would you guys add it to the trunk and go through the trouble of keeping it updated? i.e: official "support". Is there enough interest inside the team? That's all I want to know.

Probably not. This really seems like the sort of thing that would do well as an addon and maintained externally from the core. Just because it is maintained externally doesn't mean the support is bad. Some Ogre addons have great support and maintenance.