Page 1 of 1
Indigo SDK 15
Posted: Thu Feb 12, 2009 6:14 pm
by OnoSendai
http://www.indigorenderer.com/dist/IndigoSDK_15.zip
Changes:
* The SDK does everything now, network rendering etc..
* You have to save the scene to disk and then the DLL will load it from disk, for now. Use .igmesh files for the meshes when doing this.
* All IndigoInterface1 method calls are non-blocking now.
Please see the example file indigo_dll_usage_example/Driver.cpp for an explanation of how to use the SDK now.
This is a bit of a WIP release, so some stuff is disabled, like getting the HDR buffer, and the documentation isn't updated.
Re: Indigo SDK 15
Posted: Thu Feb 12, 2009 7:53 pm
by fused
fantastic, thank you!
OnoSendai wrote:* All IndigoInterface1 method calls are non-blocking now.
Posted: Thu Feb 12, 2009 7:55 pm
by suvakas
Hey,
A small question: Will it be the .igmesh files from now on and no direct-to-memory export?
If so, then I am sad. It doesn't fit with my plans and the logic of my project. External file doesn't make any sence when doing a full integration and not an exporter.
Please, please bring the direct to memory export back. Please?
[edit]
OK, got my answer in chat. It will be back later
Thank you Ono!
Posted: Fri Feb 13, 2009 2:29 am
by rgigante
WOW! Business light speed!
Posted: Fri Feb 13, 2009 12:33 pm
by fused
in case any one of you is wondering why indigo doesnt render: you need the inifile.xml inside the binaries folder.
i somewhat got it working with my plugin, but after a rendering stops c4d crashes. it seems that destroyOb() is never called, and i guess its related to that (confusing, since im using the IndigoHandle exactly like i used it in the old sdk).
it really is just a wrapper around the indigo_console.exe and definitely WIP. it does even save a png if a "renders" folder is present, with tonemapping, so make sure you set the save period very high.
i miss processXMLElement()
didnt try updateXMLElement() or any of the other new stuff yet, and i wont do that until i know the source of the crashes.
all in all, it was a bit annoying to get it working and im nowhere next to where i was before. i still have to rewrite the mesh export for igmesh and lots of other stuff. my code went from quite clean to ugly, confusing and full of TODO comments
BUT
its great to have a fully functional version!
now i can finally mess with interactive tonemapping ^^
Posted: Fri Feb 13, 2009 8:38 pm
by fused
also, the buffer returned by indigo is always 4 pixels higher/wider than the size you set (eg 320x240 / 324x244). guess thats for getting rid of the 1-2 pix dark border that was there in (much) older versions of indigo and in the old sdk.
Posted: Sat Feb 14, 2009 12:16 am
by rgigante
Bigger buffer was a known "bug". But if u crop the image while displaying it's correct
2c, R.
Posted: Sat Feb 14, 2009 12:41 am
by fused
rgigante wrote:Bigger buffer was a known "bug". But if u crop the image while displaying it's correct
2c, R.
yep, thats what im doing, it was just a note for you guys. i didnt experience this in older sdk versions...
Posted: Mon Feb 16, 2009 12:22 am
by fused
ok, checked it with the older version, destroyOb isnt called the way i use it...
crashing is still confusing...
heres what i do: i have a global class that handles all the indigo stuff (for various reasons; it handles queueing and interactive tonemapping and such).
this class looks somewhat like this:
Code: Select all
class IndigoClass
{
public:
IndigoClass() {
indigo = IndigoHandle<IndigoInterface1>(NULL);
};
Bool LoadDLL() {
...
};
Bool CreateIndigoInstance() {
...
};
void InitRendering() {
LoadDLL();
CreateIndigoInstance();
//return TRUE;
};
Bool StartRendering() {
//check pointer
if (!indigo.getPointer()) return FALSE;
indigo->startRendering();
return TRUE;
};
Bool EndRendering() {
//check pointer
if (!indigo.getPointer()) return FALSE;
//stop rendering
indigo->startTerminateRender();
// Wait for rendering threads to stop
while(!indigo->isRenderTerminated())
{
GeSleep(50);
}
Unload();
return TRUE;
};
IndigoHandle<IndigoInterface1> GetIndigoHandle() {
return indigo;
};
void Unload() {
indigo = IndigoHandle<IndigoInterface1>(NULL);
if(dll_handle != NULL)
{
const BOOL res = FreeLibrary(dll_handle);
dll_handle = NULL;
//assert(res != 0);
}
};
~IndigoClass() {
Unload();
};
private:
HINSTANCE dll_handle;
IndigoHandle<IndigoInterface1> indigo;
};
it does a bit more that that, but basically, thats it.
this works perfectly fine with sdk 13, with sdk 15 its always crashing with an access violation ~a second after the rendering stopped.
maybe this is just me being stupid again
any idea, nik (or others
)?
(maybe the indigo handle isnt placed that well in the global class, i think ill move it out of there and put it in the part of my plugin that does the exporting and rendering.)
cheers
edit: its of course far from thread safe, but i dont worry about that for now
eidt: luckily thers a Semaphore class in the c4d sdk
Posted: Mon Feb 16, 2009 11:18 am
by fused
heh, never mind! there was an uuuuuuuuuuuuuuuuuuugly memory leak that caused that crash! c++ is dangerous...
or maybe it was because i was using new and delete instead of c4ds gNew/bNew and gDelete/bDelete.
no matter what the problem was - im happy
Posted: Tue Feb 17, 2009 11:22 am
by fused
thought id share this
Posted: Tue Feb 17, 2009 11:25 am
by OnoSendai
sweet
Posted: Tue Feb 17, 2009 7:29 pm
by suvakas
Indeed, looks cool.
Posted: Tue Feb 17, 2009 8:28 pm
by fused
thx
i was wondering about the "white_point" xml...
is it a regular xml element i can use in the igs file or can i only use it with updateXMLElement()?
if its a regular xml element, i assume it overrides the "white_balance" in the "camera element". is that correct?
id dump the usual white points then, because this gives me more freedom plus itd allow a custom whitepoint setting without using the interactive tonemapping stuff.