Forums
You are not logged in.
#1 2007-02-15 01:55:59
- scorpion007
- Member
- Registered: 2007-02-06
- Posts: 49
Performing in-memory rendering and retrieving the results?
Hi,
I am aware that I can make a C application to render an image to an existing display driver, but what if I wanted to somehow get a pointer to the pixel data so that I could display it in a custom application, such as my own framebuffer? Would I have to write my own display driver for this?
If so, then it's kind of like having 2 separate applications (processes) running.
Is it possible to achieve something like the following pseudo code?
RiBegin();
.. send geometry to renderman
RiEnd();
Pixel *data = RiSomeHowGetRenderedData();
WriteDataToMyOwnFramebuffer(data);
Any tips?
Offline
#2 2007-02-15 05:54:53
- olivier
- 3Delight Developer
- Registered: 2007-01-09
- Posts: 1930
Re: Performing in-memory rendering and retrieving the results?
You need a special display driver for this. It does not however imply a separate application or process. A display driver is only a shared library. It is also possible to write a display driver which will output the data to a buffer you supply. So it could be like:
Pixel *data= new Pixel[whatever];
RiDisplay( "?", "memorybuffer", "rgb", "bufferpointer", &data, RI_NULL);
RiWorldBegin();
RiWorldEnd();
WriteDataToMyOwnFramebuffer(data);
It's a pretty easy thing to write and I have been considering adding it to 3Delight for some time.
Also, what you propose would not work because the rendered data is discarded as soon as it is sent to the display drivers. The RI was designed that way because it was not uncommon back then for the rendered pixels to exceed available memory. It still happens sometimes today.
Offline
#3 2007-02-15 09:07:06
- TwinSnakes
- New member
- Registered: 2007-01-31
- Posts: 5
Re: Performing in-memory rendering and retrieving the results?
I asked this before but was ignored....totally ignored. (I think my email was blocked er something)
I think it'd be a great feature. I've been wanting to update ShaderMan to use something like this to do shader previews. But, didnt want to invest allot of time coding the display driver.
Offline
#4 2007-02-15 11:08:57
- olivier
- 3Delight Developer
- Registered: 2007-01-09
- Posts: 1930
Re: Performing in-memory rendering and retrieving the results?
It's possible, we block a lot of spam at the ISP level and still get 80-90% spam in the 3Delight inbox. I think we must now be aware of every "great opportunity" on the planet :)
I'll try to find some time to code that thing soon.
Offline
#5 2007-02-15 16:35:14
- scorpion007
- Member
- Registered: 2007-02-06
- Posts: 49
Re: Performing in-memory rendering and retrieving the results?
olivier wrote:
Also, what you propose would not work because the rendered data is discarded as soon as it is sent to the display drivers.
Ok, but using the RiDisplay function and sending the data to a custom buffer would work, right? (Like you showed)
Offline
#6 2007-02-16 00:07:26
- scorpion007
- Member
- Registered: 2007-02-06
- Posts: 49
Re: Performing in-memory rendering and retrieving the results?
Ok, so lets say I have written a display driver. How does the system know which shared library the driver resides in?
Is the way this is done by copying the built dll file into $DELIGHT/displays/ and naming it in a certain way, or something?
So if my driver is called "my_driver", and I name the file "my_driver.dpy" and copy it to the correct folder, it will work? Or is there something else I'm missing?
EDIT:
Nevermind, I just realized that was a stupid question...
Last edited by scorpion007 (2007-02-16 02:22:51)
Offline
#7 2007-02-16 07:27:29
- olivier
- 3Delight Developer
- Registered: 2007-01-09
- Posts: 1930
Re: Performing in-memory rendering and retrieving the results?
scorpion007 wrote:
Ok, but using the RiDisplay function and sending the data to a custom buffer would work, right? (Like you showed)
Yes.
As for your other question, there are several options:
1) Put the file somewhere in the DL_DISPLAYS_PATH ($DELIGHT/displays is included in there by default)
2) Specify the full path to RiDisplay (as the display name)
3) use the /display/dso/displayname option in rendermn.ini. This allows you to specify which library should be loaded for a given display name.
In all cases you can name the library .dpy or whatever else you want. If you name it something other than .dpy, .dll or .so, you'll need to specify the extension in the display name. Makes me think we should probably add dylib to that list :]
Offline

