Blendigo 2.4 Stable (Update #2)

[dougal2]

Update #1 24th Sept 2010

Update #1 fixes a bug introduced in the last release that causes a divide by zero error on export.

Update #2 28th Sept 2010

Update #2 fixes a bug introduced in the last release that causes additional command line arguments to fail (eg. network rendering).
Also in this release:
- Sexy new Windows installer

KNOWN ISSUES

- Not 100% backwards-compatible with scenes set up with Blendigo 2.2 stable; especially with regards to material settings. This won't be fixed, you'll need to migrate your old scenes to the new Blendigo if you wish to re-render them with Indigo.

DOWNLOADS FOR UPDATE #2

WINDOWS: http://www.indigorenderer.com/dist/expo ... taller.exe

LINUX: http://www.indigorenderer.com/dist/expo ... e.2.tar.gz

OSX: http://www.indigorenderer.com/dist/expo ... able.2.zip

New in this release:

* Particle instance motion blur - WARNING: will cause long export times and potentially huge scene files
* Fixed material albedo texture UI always switching back to colour, even if texture used
* Some small optimisations to igmesh writer

YOUR FEEDBACK IS ALWAYS APPRECIATED

Despite this release being marked as stable, please do report any problems found.

[StompinTom]

Whoop whoop!

Not sure if this has been fixed (downloading now) but when rendering animations, Indigo just stops when it reaches the desired sample count/time limit and doesn't close, thus preventing the next frame from starting. Will confirm, but it prevents rendering fly-by animations right now.

Thanks for the hard work, Doug!

[dougal2]

Whoop whoop!

Not sure if this has been fixed (downloading now) but when rendering animations, Indigo just stops when it reaches the desired sample count/time limit and doesn't close, thus preventing the next frame from starting. Will confirm, but it prevents rendering fly-by animations right now.

Thanks for the hard work, Doug!

oh, I added the close on halt option too, underneath the halt settings

[StompinTom]

Whoop whoop!

Not sure if this has been fixed (downloading now) but when rendering animations, Indigo just stops when it reaches the desired sample count/time limit and doesn't close, thus preventing the next frame from starting. Will confirm, but it prevents rendering fly-by animations right now.

Thanks for the hard work, Doug!

oh, I added the close on halt option too, underneath the halt settings

Excellent! I'll give it a spin today and let you know if I can break it

[StompinTom]

Problem with motion blur or something:

I rendered a few frames of an animation using the fly-by mode. Now when I hit 'Render', it throws a 'ZeroDivisionError: float division' that appears to be related to 'keyframe times = getMoBlurTiming(startF)'.

Don't have the exact console log here as it's happening on another machine, but it's preventing me from doing any rendering with my scene

[dougal2]

Hi Tom,
I've identified the problem and will get another release out very soon.

[pixie]

2.49 or 2.5?

[StompinTom]

2.49 or 2.5?

2.49

Doug, thanks, I look forward to it!

[StompinTom]

Idea for batch rendering: Same as with animation (boots that little program that keeps feeding frames to Indigo) however you could specify the cameras you want to render out in Blendigo, set up stop time/sample limit and it will throw out renderings from each of those cameras.

You could do it by animating the camera to be in a different position each frame and then just booting up a fly-by animation of those individual frames, but that's a bit of a workaround. It would be perfect for those long weekends when you're away from the computer but still need a set of views done for Monday.

[dougal2]

Idea for batch rendering: Same as with animation (boots that little program that keeps feeding frames to Indigo) however you could specify the cameras you want to render out in Blendigo, set up stop time/sample limit and it will throw out renderings from each of those cameras.

You could do it by animating the camera to be in a different position each frame and then just booting up a fly-by animation of those individual frames, but that's a bit of a workaround. It would be perfect for those long weekends when you're away from the computer but still need a set of views done for Monday.

This is good idea, in fact it could be extended to render (all) cameras in (all) scenes in a blend file. Most likely though, this will only be feasible to implement in Blender 2.5 at a later date when the core export process has been well tested.

[dag]

FastBox can only be used for splat... you also added it to downsize.
Got an idea why particles won't emit light? ---> bottom

[FakeShamus]

I noticed this too, the luminous flux parameters of an emitter are linked with the model now instead of the material. the exported particle instances are missing that data.

on a (sort of) related topic, how do you change the material of instanced objects? it seems that the material is always linked to the mesh itself. is there a way to make, say, your original cube red and the instanced copy of it blue?

[dougal2]

I noticed this too, the luminous flux parameters of an emitter are linked with the model now instead of the material. the exported particle instances are missing that data.

on a (sort of) related topic, how do you change the material of instanced objects? it seems that the material is always linked to the mesh itself. is there a way to make, say, your original cube red and the instanced copy of it blue?

I'm not sure this is possible, since the name of material to use is embedded in the exported mesh data (igmesh). It might be possible to redefine the material before each instance's <model> tag, but I'm not sure that would work, or if it did it might turn out to be very inefficient in terms of data exported and export time.

I wonder if Ono could arrange for a <material_name> tag in the <model> rather than specifying it in the mesh data ?

[dougal2]

The reason the material is linked with the mesh definition is because of the support for per-triangle material assignment (ie, multi materials on the same mesh).

Obviously, this conflicts with changing the materials on each instance, as the mesh would need re-defining.

[FakeShamus]

the way this used to work was the mesh and the material were first defined in the scene as usual and then the code in the igs looked something like:

<model> placing the mesh in the scene (position, scale, etc)

<material> (same material name as first, but redefined with different parameters)

<model> (new instance of the same mesh, but now the material for it has been redefined for that particular model) along with position, scale, etc...


but this was way back when I would dig into the scene code and tweak everything by hand (fun times).
I don't even know if Indigo parses the scene file in the same way anymore. haven't tried it in a while.
and there's probably not an easy solution to implement this in blendigo since it relies on defining different materials using the same material name.