Shading for Real-time Applications
Monday, February 08, 2010
Progress Report w5
in Shading for Real-time ApplicationsThe past week I have been working on a project to have the CLI process to send messages over to the Nebula process. The server and client code has been written or setup but I haven’t succeeded to make the server receive messages from the client. Will look more into this the following week. I have also taken a look into loading alternating renderpaths into the Nebula engine to use costume shaders. Hopefully I will have my prototype ready this week consisting of the two processes communicating using a renderpath with my own HDR shaders.
Shading for Real-time Applications • Add comments (0)
Friday, January 29, 2010
Progress Report w4
in Shading for Real-time ApplicationsWhat did I plan to do this week?: This week was going to focus on setting up an implementation of a simple CLR program that was using the Nebula3 engine to render a demo scene that came with the SDK. I was also going to try diffrent approches of how to implement the communication between the CLR process and Nebula render process.
What did I actually do?: I spent the first days trying to compile managed CLR code together with unmanaged Nebula code using the preprocessor to distinctive the different parts. This approach gave a lot of problems when the compiler came to the Linker stage. The problems can be summed up into that it complained about that the Nebula library files was compiled with a different native then CLR applications.
So I decided to try from the other end, making an Nebula application that was going to be costumed to listen to commands from the CLR process. This however had other problems. First I tried to create a empty Win32 project setting up an instance of Nebula but in the end got the same native problem even when I used the exact same source code a working sample project that came with the SDK. From here I decided to copy a sample project from the SDK and just modify it into what I needed. This worked fine of course and the reason it did is that I noticed why now that the sample projects uses a custom set of build rules. I haven’t spent any time going through what this does to the compiling process, but perhaps modifing in this file might have gotten my first CLR ompile to work. So I have a working Nebula code that is ready to be used.
I have also looked through the source code of Nebula and done some more research about the approaches I posted in my last blog. And I am considering to make the process communication through sockets. Why? I noticed that implementing a Shared Memory would take about more work both the DLL implementation but also the modification of the engine. Though it’s still a possible solution to fall back on since it’s the best solution to move a lot of data between processes. Not that much moving much data is critical for this project.
Another approach was to use inter-process communication, this works by using the operative system message system to send messages between processes. The problem with this solution is that this requires that I need to modify the WinProc function inside Nebula in order for it to process my messages, which isn’t an optimal thing to do and I might need to make more modifications then I can make out right now. But it is a good solution since the communication in my project is mostly only going to be small messages.
The last solution is to make the same type of implementation but to send the messages through sockets. The good in this solution is that Nebula has a built in support for tcp communication and I could just implement a support to process the messages I need to send. And this solution makes it possible to even run Nebula on one computer and the CLR tool on another. So this will be the implementation of my chose.
What will I do next?: Next step will be to make a implementation of the process communication through sockets with the CLR process and the Nebula program. And also take a look at the implementation of HDR (yes I have decided to switch the plan of the next 2 weeks in case the process communication takes to much time and HDR is a higher priorities shader to implement).
Shading for Real-time Applications • Add comments (0)
Monday, January 25, 2010
Milestone1
in Shading for Real-time ApplicationsToday the first milestone of the project was presented and the project plan is uploaded for display. I will probably make a couple of updates to the project plan as I’m implementing the prototype this week.
A better version of the research document will come up today or tomorrow as well as some detailed description in the blogs about field.
Most of the work this week will be to implement a Small CLR application that runs the Nebula3 engine to render a simple scene.
A final approach is to split up in processes like approach 2 but use an TCP/IP communication instead of an DLL. It has it’s benefits but from a tool development point of view
it doesn’t give as much windows programming experience as I would like.
So I have a couple of ways to go with this and will try them in the above order. How ever, if the first approach doesn’t have an quick solution I will go with number 2.
Shading for Real-time Applications • Add comments (0)