Indigo SDK 15

[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.

[fused]

fantastic, thank you!

* All IndigoInterface1 method calls are non-blocking now.

[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!

[rgigante]

WOW! Business light speed!

[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 ^^

[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.

[rgigante]

Bigger buffer was a known "bug". But if u crop the image while displaying it's correct

2c, R.

[fused]

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...

[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

[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

[fused]

thought id share this

[OnoSendai]

sweet

[suvakas]

Indeed, looks cool.

[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.