Shading for Real-time Applications
Progress Report w4
What 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).
Next entry: Short film, HVFX - filming and texturing complete
Previous entry: Peasant Village - Meatsnake WIP 2