Page 1 of 1

[GSoC 2012] Networked render system (prev. null renderer)

Posted: Thu Mar 29, 2012 5:05 pm
by Yatenkou

I edited my proposol
, see http://www.ogre3d.org/forums/viewtopic. ... 93#p455532 (link leads to this topic lower post)


old proposal:

Hi,
i am planning to participate in this year's Summer of Code and am interested in creating a null render system for Ogre.
Since i am not as experienced with Ogre as i would like to be (i only worked on one self-project in Ogre up until now, a minecraft-like game) i wanted to make sure that i understand the requirements for this task correctly before i apply.

As far as i understand the goal is to create a new render system for mainly 2 cases:
1. to be able to run Ogre on a Server without a graphic card and
2. to easily swap the render system for graphic card independent testing.

I had a look at existing render systems, and i think i can divide the task in 3 major areas:
a) removing from an existing render system all rendering stuff (or is culling and recycling of code frowned upon?)
b) changing the hardware buffer usage to software buffers. Maybe this is already possible by using the defaultHardwareBuffer classes, i have to investigate more in that direction. But if its not, it should not be too difficult coding a SoftwareBuffer system.
c) testing (after and during work) and refining documentation

What i have doubts about is the workload: Isn't it too little for a SoC project? I don't think this project takes 4 months to complete.
Am i underestimating the workload, or forgetting a task that might be work intensive?
In the case i dont, is it allowed to apply to 2 projects (of Ogre), one of those as a follow-up project? (I wouldnt mind finishing it after the SoC has ended)

I am grateful to any input from you, to any of those points!

Re: [GSoC 2012] Null render system

Posted: Thu Mar 29, 2012 7:57 pm
by spacegaier
One previous implementation has been done some time back ago here: http://www.ogre3d.org/forums/viewtopic.php?t=28954 (last link on page 1 of that thread)

Re: [GSoC 2012] Null render system

Posted: Thu Mar 29, 2012 8:37 pm
by jacmoe
It is definitely not as easy as it sounds. :)

A lot of people have wanted this over the years, but so far: zero implementations.

Re: [GSoC 2012] Null render system

Posted: Thu Mar 29, 2012 10:27 pm
by Yatenkou
thanks spacegaier, i already had a look at that thread and implementation, but i still need to have a closer look at it this weekend - apparently it can't be compiled, and i'm currently not in my work environment (which is at home :D). I can't tell yet how much it was functioning "back in its days".

@jacmoe you are right, it really seems like it was proposed and requested a few times but no working implementation as of now. It probably is not as easy as i thought it would be - but that kind of improves my motivation even more :)

On a side note, i would also be really interested in developing a transition system for scenes. I could imagine it to be a nice feature in almost every application (for example a nice fade-in at the start of the application, nice transitions for loading screens, etc.). But from which development would ogre in general benefit more?

Re: [GSoC 2012] Null render system

Posted: Thu Mar 29, 2012 11:46 pm
by jacmoe
It could also be useful for testing.

If you mock the Ogre:
http://www.ogre3d.org/forums/viewtopic.php?f=5&t=47247

Last post in that topic contains a link to a mocked version of Ogre (AFAIK) - haven't had the time to take a proper look at it.

Re: [GSoC 2012] Null render system

Posted: Fri Mar 30, 2012 12:07 pm
by Yatenkou
Mocking sounds actually a lot like what i coded for another project in Java a few years ago. I used AspectJ(http://www.eclipse.org/aspectj) which can be used to inject code at runtime at predefined points, for example method calls. I wrote a test module that would log method access, and could also be used to skip or replace methods or return default values from them.
What sounds nice to me is the ability to not only replace methods, but also the objects themselves. And Google Mocking is probably a lot cleaner and more powerful than the API i hacked back then :D

Are you thinking about using it instead of coding a null renderer? I am not really sure about that myself. It would probably be easier and cleaner to implement, and also work for testing, but then one of the goals of being able to run Ogre without a graphics card would be lost. I guess it depends on how important that feature (ogre without graphics card) really is, i've read in some threads that people wanted it for servers, but i guess most people would design their server applications without ogre anyway.

I had a look at the mocked version of ogre - in general the design looked nice, although the creator only seems to have mocked the (few) methods he himself uses (which of course makes kind of sense...).

Re: [GSoC 2012] Null render system

Posted: Thu Apr 05, 2012 3:57 am
by Assaf Raman
Add your project to here before student application deadline.‬

Re: [GSoC 2012] Null render system

Posted: Thu Apr 05, 2012 9:35 pm
by jacmoe
It's ironic that I know of an existing null renderer, but it's of no use to anyone since it's licensed under the GPL. ;)

[GSoC 2012] Networked render system (prev. null renderer)

Posted: Mon Apr 09, 2012 7:57 pm
by Yatenkou
Following a suggestion I change/extend my proposol to the following project: A networked render system. This would still kind of fulfill my previous project idea, the null render system, but more to that a bit later.
I would create a render system which gathers the render calls on the server, transmits them over the network to one or multiple client systems (via UDP or maybe even TCP) where the input is finally rendered.
A few examples how such a feature could be utilized are:
- remote visual debugging of a server
- video transmission
- logging into a game client to see what the user can see (user support)
- running a server without video card (more to that later)

Technically this would work by creating two different networked render systems, for now let's call them serverRenderSystem and clientRenderSystem. The serverRenderSystem receives render calls and sends those calls to one or multiple clientRenderSystem (which have subscribed at the server beforehand), where the image is rendered.
The serverRenderSystem would optionally also have a normal render system (e.g. OpenGL), therefore the server can additionally also render the render calls by itself.

In a nutshell:
render call -> serverRenderSystem -> (optional) copy render call and render by itself -> send render call to clientRenderSystem
Since the copying and display of render calls on the server itself is optional, the networked render system can also be used as a null render system: Simply do not send the render calls to a client, and do not copy the render calls.


I will try to create the networked render system highly flexible, e.g. to allow for a scene to be split into multiple parts, and only one part is sent to each client. To illustrate what I mean please bear with my not very artistic paint drawing attached to this post, or see the following link:
http://www.ogre3d.org/tikiwiki/High+res ... creenshots

It goes in the direction of a render farm, but probably not quite yet, because for now the goal would not to be to render faster, but display an image split on multiple output devices. This might be a feasible extension though. (note: it is of course possible to render on different systems and thus multiple video cards, but the result of the rendering is not transmitted back to the server, if you know what I mean)
This could be useful for e.g. Display Walls or Virtual Reality. The feature would probably work by splitting the source image into multiple render windows by the user, the networked render system then creates and manages "render streams" for each such render window. Those can be requested by one or multiple clients at will. I'm not sure about the need for multiple render windows to implement the feature, that is just the way I think it will work for sure. Another possibility that comes to my head and I need to further look in to is one viewport = one network stream.


Schedule:

until Mai 14.
Get to know mentor/mentors better.
Further strengthen my knowledge of the Ogre source code and look into existing render systems.

Mai 15. - Mai 21.
Set up development environment, ascertain the workflow is working without problems.

Mai 22. - June 10.
Create and refine the implementation plan (e.g. which transmission protocol, options when creating render system, ...).
Discuss project and ideas with mentor/mentors.
Also run basic tests for remote rendering, explore difficulties and problems.
 
June 11. - June 14.
Create communication protocol between server and client render system
 
June 15 - July 02.
Start implementing the server render system, goal of this step: working rendering on server system and null render system.
Dummy functions and calls for transmitting render calls to client system.
 
July 03. - July 20.
Start the work on client render system and implement the network code, the registration of the clients at the server, the sending of render calls from the server to clients and reception by clients)
 
July 21. - July 28.
Complete client server system (Rendering part).

July 29. - August 07.
Testing

August 08. - August 12.
Complete the Documentation
  
August 13.
Suggested pencils down date
 
August 13. - August 19.
Buffer / split rendering
 
At the end of GSoC i will have finished:
1. Working networked render system (server and client)
2. Documentation

After GSoC
Finishing the split rendering part if not already done, also render farms if there is interest.


I am glad about any suggestions/input/comments you might have, and also ideas for better implementation of the "Split Rendering" part.

Thanks for reading! :-)

Re: [GSoC 2012] Networked render system (prev. null renderer

Posted: Sat Apr 14, 2012 3:59 pm
by Mattan Furst
I think that creating a network rendering mechanism would be better served if it was moved render system API level to a higher API (Ogre API or above). I believe not doing so will present difficulties performance-wise. There are 2 main reasons for this:

The first reason is the needed amount of data throughput that you will need to send through the network. Consider how API calls to ogre are translated to render system calls. A single call to load an entity, in the render system level, becomes loading large buffers containing vertex data index data and images. enabling an animation becomes, at the best, sending the entire list of bone matrices every frame, at worst, sending the entire vertex buffer every frame.

The second reason is camera rendering logic scalability. The system will be good for rendering large flat areas, but consider instead what happens with domes with 180 degree view or more. In this case you will need different cameras to render different angles. With the network rendering mechanism being implemented at the render system level, you will still need to run the logic of rendering a camera at the server side for these types of situations. This makes the system un-scalable. Adding twice the amount of cameras/client computers will still mean that the server will need to work twice as hard.

Consider instead an implementation in which a system, instead of calling the Ogre API directly, calls an Ogre wrapper. The ogre wrapper transmits the API calls to a network of computers each with their own client running an Ogre component. I realize this is not a strait forward solution. There are a lot of factors to considered in this case such as how different cameras are controlled, how to handle the separate object pointers, as well as the creation of free/manual objects. But if you're thinking of a scalable solution for network rendering I believe this is a better way to go.


Edit:
Rereading your post I realize that what you intended for this system is not what I had in mind when I read the new title. I Do realize now that there are some aspects of the system you proposed that can only be achieved by implementing this system on the render system API level.

Re: [GSoC 2012] Networked render system (prev. null renderer

Posted: Mon Apr 23, 2012 9:56 pm
by Assaf Raman
Sorry, but you didn't make it this year, thanks for your effort, you have to understand - we are only 3 mentors and had only 4 spots.

Re: [GSoC 2012] Networked render system (prev. null renderer

Posted: Mon Apr 23, 2012 11:11 pm
by spacegaier
Also a "Sorry!" from my side. It was a difficult choice for us, but as Assaf said, we of course only have a limit pool of resources :( .

We however are naturally still interested in that project, even if not as a GSoC project. So if you have the time and motivation, feel free to start the project anyway. I think there are quite some use cases for such a system.

Re: [GSoC 2012] Networked render system (prev. null renderer

Posted: Thu Apr 26, 2012 5:56 pm
by Yatenkou
hey, no hard feelings from my side!
I think I will start the project anyway like you said, but won't promise any results yet ;-)

Re: [GSoC 2012] Networked render system (prev. null renderer

Posted: Thu Apr 26, 2012 7:56 pm
by spacegaier
If you would create an Ogre fork on BitBucket it would be easy for the community to follow your progress and easily do pull requests in the future.