Indigo Renderer Forum

3.2.2.0

DOWNLOADS

ALL PLATFORMS: http://www.indigorenderer.com/dist/expo ... .2.2.0.zip

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

NOTE: This exporter REQUIRES Blender version 2.60

Changes in this release:

* make version check more robust
* corrected IndigoConsole name for OSX
* fixed light layers for Sun+Sky
* fixed obstacle map path
* extended proxying to accept .obj files
* improved proxying by not loading igmeshes; however material assignments are now user resposibility
* fixed crash with unassigned CRF
* fixed failed lights check for env_map with relative path on c:
* fixed UV indexing

MANUAL INSTALLATION

Unzip the archive. Move the extracted indigo folder into your Blender addons folder.
You should end up with <blender scripts>/addons/indigo/

Run Blender 2.6, go into User Preferences/Addons, and find the Render section. Locate the Blendigo entry
and enable the addon by clicking the little checkbox on the right.

INSTALLATION VIA BLENDER

Run Blender 2.6, go into User Preferences/Addons. Click the "Install Addon" button and choose the blendigo-2.5-3.2.2.0.zip file. The addon will be installed and shown to you, ready for activation.

This method _should_ automatically replace any previous version. You can easily check the installed version in the Addons panel. After upgrading/replacing I would strongly recommend restarting blender.

HINTS

Save your User Settings now to make Blendigo activate every time you start Blender 2.6.

Non-windows users will have to also fill in the "Path to Indigo" setting in the "Indigo Render Engine Settings"
panel. (Windows does this automatically from the information provided by the installer). Note that you should
specify the actual Indigo binary file for this setting.

YOUR FEEDBACK IS ALWAYS APPRECIATED

As with the current efforts to get Indigo 3.x as complete and user-friendly as possible,
please please keep reporting any issues you find with Blendigo - it is your feedback as
users and artists alone that push Blendigo forward into being the software that works for you.

Thanks! Off to test...

I report the bug with large tri again, bug was find by Thomas from indigo support team.

Thomas: I used the latest Blendigo from the forum, version 3.2.2.

Also, I know what's causing this issue now, and it's basically bad geometry. Vertex normals are formed from the face normals of the triangles/quads that touch it, and they are added together before making the final normal. So, I looked at the vertex normals, and found that one of them has a normal vector of ZERO (0,0,0)!

Confused as to how this is could be, I looked at all triangles which affect the normal of a broken vertex, in this case vertex number 1276:

tri 2 touches vertex 1276 with normal < 0.000000 0.000000 -1.000000 >
tri 1 touches vertex 1276 with normal < 0.000000 0.000000 1.000000 >
tri 0 touches vertex 1276 with normal < 0.000000 0.000000 -1.000000 >
tri 0 touches vertex 1276 with normal < 0.000000 0.000000 1.000000 >

So there are 4 surfaces using this vertex - two point straight up, and the other two point straight down! Together the influence is exactly zero, it doesn't point anywhere.

Clearly this makes no geometric sense, and neither the exporter or Indigo can produce a correct result from such a surface description. In your mesh, you should make the vertices which are part of up-facing surfaces not shared with those which are pointing down (otherwise it tries to be both at the same time). Given a consistent surface description, it renders correctly.

I disabled it in the XML (opened the exported scene in Notepad, ctrl+f for "smooth", set "true" to "false"). If there isn't a thing to disable it in Blendigo that's a bug and should be added!

Is it related to autosmooth? I desable it with "smooth" desable and still didn't work.

Can it be fixed?

Thanks

@Jambert,

As Thomas says, this is down to having bad geometry in the first place. Have you tried "Make normals consistent" on the object in question?

In the next release I will add a mesh option to force disable smoothing, which should help.

dougal2 wrote:@Jambert,

As Thomas says, this is down to having bad geometry in the first place. Have you tried "Make normals consistent" on the object in question?

In the next release I will add a mesh option to force disable smoothing, which should help.

I always work with export from Solidworks, I can't manualy clean all my mesh. But I understand that mesh exported are realy bad... Maybe at the moment, it's easier for me to use unix "sed" tool to auto-correct .xml

proxy with .obj is working great, thanks a bunch for that!

I've not had that problem with SW exports but don't do that too often. I always use STL export. And then use ctrl-n to recalculate normals.
I do NOT use "remove doubles" as that can make a real mess out of dense meshes if you don't watch the threshold.

Is it possible to add an option to ignore the version control? Sometimes it's useful to mix and match Indigo/Blendigo versions, especially when testing out new builds...

EDIT: Or at least perform the version check BEFORE exporting everything?

StompinTom wrote:Is it possible to add an option to ignore the version control? Sometimes it's useful to mix and match Indigo/Blendigo versions, especially when testing out new builds...

EDIT: Or at least perform the version check BEFORE exporting everything?

To be honest, I'm not a massive fan of this feature, but Glare asked me to do it. The idea with how it currently works is that the scene does always get exported so that you can then load it with a "mismatched" version if you know what you are doing

dougal2 wrote:

StompinTom wrote:Is it possible to add an option to ignore the version control? Sometimes it's useful to mix and match Indigo/Blendigo versions, especially when testing out new builds...

EDIT: Or at least perform the version check BEFORE exporting everything?

To be honest, I'm not a massive fan of this feature, but Glare asked me to do it. The idea with how it currently works is that the scene does always get exported so that you can then load it with a "mismatched" version if you know what you are doing

Ah ok, so it doesn't stop you from rendering it with a different version, just doesn't do it from Blender. Proxy export works great! Hopefully I'll get a chance to make a quick forest or something soon to show and tell.

Hi,

Thanks for new build! I think it was mentioned somewhere before, but there's a problem with rendering animations. When I'm trying to render blendigo start rendering of each frame simultaneously, instead queuing them one after another. That makes animation rendering impossible. Is there any workaround to that?

Otherwise works great for me!

Autostarting still does not seem work on OSX, however, for a different reason, according to the consoleL

11/16/11 9:44:08.302 PM [0x0-0xdc0dc].org.blenderfoundation.blender: Error: Unsupported version v0.0.0; Cannot start Indigo with this scene

Machine and OS specs are in the sig.

Shouldn't material colors export with 2.2 gamma?
With gamma 1 they are very bright, won't match textures and 2.2 is used when adding new material in indigo.

there is still an issue with the paths for nk files on OSX.
I found out what it is though - if you just type in cr.nk, for example, seems that Blendigo is looking for the file in just the "resources/" folder, when it should be looking in "resources/nkdata/"

so it works if you type in "nkdata/cr.nk"
but it still gives me an error if I browse to the nkdata folder from Blendigo.

FakeShamus wrote:there is still an issue with the paths for nk files on OSX.
I found out what it is though - if you just type in cr.nk, for example, seems that Blendigo is looking for the file in just the "resources/" folder, when it should be looking in "resources/nkdata/"

so it works if you type in "nkdata/cr.nk"
but it still gives me an error if I browse to the nkdata folder from Blendigo.

Thanks for letting me know, the nk stuff hasn't been looked at sine the first implementation I don't think and can certainly be cleaned up to work like the camera tonemapping - using presets/file.

One thing I wanted to ask about OSX - do the camera tonemapping presets show up properly now? I don't have a Mac to test on at the minute