Indigo SDK 15

A private discussion forum for users of the Indigo Renderer SDK. Send a private message to OnoSendai if you want access.
Post Reply
14 posts • Page 1 of 1
User avatar
OnoSendai
Developer
Posts: 6182
Joined: Sat May 20, 2006 6:16 pm
Location: Newcastle upon Tyne, UK
Contact:

Indigo SDK 15

Post by OnoSendai » Thu Feb 12, 2009 6:14 pm

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.

User avatar
fused
Developer
Posts: 3574
Joined: Fri Sep 22, 2006 7:19 am
Location: Berlin, Germany
3D Software: Cinema 4D

Re: Indigo SDK 15

Post by fused » Thu Feb 12, 2009 7:53 pm

fantastic, thank you!
OnoSendai wrote:* All IndigoInterface1 method calls are non-blocking now.
:D

User avatar
suvakas
3rd Place Winner
Posts: 2613
Joined: Mon Sep 04, 2006 11:08 pm
Location: Estonia
Contact:

Post by suvakas » Thu Feb 12, 2009 7:55 pm

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!

User avatar
rgigante
Posts: 326
Joined: Wed Jun 28, 2006 6:46 am
Location: Italy

Post by rgigante » Fri Feb 13, 2009 2:29 am

WOW! Business light speed!

User avatar
fused
Developer
Posts: 3574
Joined: Fri Sep 22, 2006 7:19 am
Location: Berlin, Germany
3D Software: Cinema 4D

Post by fused » Fri Feb 13, 2009 12:33 pm

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 :P

BUT

its great to have a fully functional version! :D
now i can finally mess with interactive tonemapping ^^

User avatar
fused
Developer
Posts: 3574
Joined: Fri Sep 22, 2006 7:19 am
Location: Berlin, Germany
3D Software: Cinema 4D

Post by fused » Fri Feb 13, 2009 8:38 pm

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.

User avatar
rgigante
Posts: 326
Joined: Wed Jun 28, 2006 6:46 am
Location: Italy

Post by rgigante » Sat Feb 14, 2009 12:16 am

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

2c, R.

User avatar
fused
Developer
Posts: 3574
Joined: Fri Sep 22, 2006 7:19 am
Location: Berlin, Germany
3D Software: Cinema 4D

Post by fused » Sat Feb 14, 2009 12:41 am

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

User avatar
fused
Developer
Posts: 3574
Joined: Fri Sep 22, 2006 7:19 am
Location: Berlin, Germany
3D Software: Cinema 4D

Post by fused » Mon Feb 16, 2009 12:22 am

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 :D

User avatar
fused
Developer
Posts: 3574
Joined: Fri Sep 22, 2006 7:19 am
Location: Berlin, Germany
3D Software: Cinema 4D

Post by fused » Mon Feb 16, 2009 11:18 am

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 :)

User avatar
fused
Developer
Posts: 3574
Joined: Fri Sep 22, 2006 7:19 am
Location: Berlin, Germany
3D Software: Cinema 4D

Post by fused » Tue Feb 17, 2009 11:22 am

thought id share this :)

Image

User avatar
OnoSendai
Developer
Posts: 6182
Joined: Sat May 20, 2006 6:16 pm
Location: Newcastle upon Tyne, UK
Contact:

Post by OnoSendai » Tue Feb 17, 2009 11:25 am

sweet :)

User avatar
suvakas
3rd Place Winner
Posts: 2613
Joined: Mon Sep 04, 2006 11:08 pm
Location: Estonia
Contact:

Post by suvakas » Tue Feb 17, 2009 7:29 pm

Indeed, looks cool. 8)

User avatar
fused
Developer
Posts: 3574
Joined: Fri Sep 22, 2006 7:19 am
Location: Berlin, Germany
3D Software: Cinema 4D

Post by fused » Tue Feb 17, 2009 8:28 pm

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.

Post Reply
14 posts • Page 1 of 1

Who is online

Users browsing this forum: No registered users and 2 guests