Indigo Renderer Forum

This is a Beta release.
If you spot any bugs or problems, please make a post about them in this thread.
Thanks!

Indigo for Windows 32-bit:
IndigoRenderer_3.6.2_Setup.exe

Indigo for Windows 64-bit:
IndigoRenderer_x64_3.6.2_Setup.exe

Indigo for Linux 32-bit:
IndigoRenderer_v3.6.2.tar.gz

Indigo for Linux 64-bit:
IndigoRenderer_x64_v3.6.2.tar.gz

Indigo for Mac OSX (10.5 - 10.7):
IndigoRenderer3.6.2.dmg


Indigo RT for Windows 32-bit:
IndigoRT_3.6.2_Setup.exe

Indigo RT for Windows 64-bit:
IndigoRT_x64_3.6.2_Setup.exe

Indigo RT for Linux 32-bit:
IndigoRT_v3.6.2.tar.gz

Indigo RT for Linux 64-bit:
IndigoRT_x64_v3.6.2.tar.gz

Indigo RT for Mac OSX (10.5 - 10.7):
IndigoRT3.6.2.dmg

Changelog:

3.6.2
* Fixed crash when coating substrate material was specular or glossy transparent.
* Fixed real-time changes for nested Coating and blend materials.

The new coating material is rendering fast ! It has also plenty of parameters to fiddle with, it's a real beast.

I was frustrated from using the thickness shader as a height field (bump), that old issue is persisting. It would be great if any procedure delivering a real could be used as a height field as well, I'm experiencing the current status as a defect.

Shared params were rejected with this release (at least, for a coating material).

I am not sure, but I think that the exponent from the substrate should prevail where the coating thickness is zero ?

PS: Nested coatings is sounding totally awesome.

CTZn wrote: I was frustrated from using the thickness shader as a height field (bump), that old issue is persisting. It would be great if any procedure delivering a real could be used as a height field as well, I'm experiencing the current status as a defect.

Not exactly sure what you mean here, can you be more specific?

Specifically, I could not figure out how to access pos from within a shader of the displacement type.

Could displacement evals accept the following signature:
wich is the one that thickness uses ? It's frustrating not to be able to use 3d noises for bumps and displacements for otherwise 3d materials.

CTZn wrote:It's frustrating not to be able to use 3d noises for bumps and displacements for otherwise 3d materials.

Never understood that too! This is a big benefit regarding texturing without the need of UV mapping stuff. Displacement bump etc of ISL noise could be done on "organic meshes" so easy by that, without any hassle!
How would you otherwise do a worn out rough surface (via bump or displacement) on for a example the Stanford dragon?!

3D textures ftw!

CTZn wrote:Specifically, I could not figure out how to access pos from within a shader of the displacement type.

Could displacement evals accept the following signature:

Code: Select all

def eval(vec3 pos) real:

wich is the one that thickness uses ? It's frustrating not to be able to use 3d noises for bumps and displacements for otherwise 3d materials.

Thickness is a wavelength-independent parameter, so it uses a

def eval(vec3 pos) real :

shader type.

There's a few reasons why displacement shaders can't so far access the world space position. First off is that it would break instancing - or at least the geometry would become position (instance transform) dependent.

The other is that a displacement effects the position, and if position in turn effects the displacement, then you get a kind of feedback loop. I guess this can be avoided by just considering the original position or doing displacement exactly once.

I'll have a look at at least making object space position (posOS()) available.

OnoSendai wrote:

CTZn wrote:Specifically, I could not figure out how to access pos from within a shader of the displacement type.

Could displacement evals accept the following signature:

Code: Select all

def eval(vec3 pos) real:

wich is the one that thickness uses ? It's frustrating not to be able to use 3d noises for bumps and displacements for otherwise 3d materials.

Thickness is a wavelength-independent parameter, so it uses a

def eval(vec3 pos) real :

shader type.

Thanks, I see the reason why it's here. Now let's discuss about what's not there.

OnoSendai wrote:There's a few reasons why displacement shaders can't so far access the world space position. First off is that it would break instancing - or at least the geometry would become position (instance transform) dependent.

I understand the issue with instances. The expected minimal functionality would be that the reference be displaced then instanced. Doesn't break a thing, and can be worked around using several variants of one shader (<- maybe in a different context, ignore that).

OnoSendai wrote:The other is that a displacement effects the position, and if position in turn effects the displacement, then you get a kind of feedback loop. I guess this can be avoided by just considering the original position or doing displacement exactly once.

Considering the original position is what I'd expect, that's streamline.

OnoSendai wrote:I'll have a look at at least making object space position (posOS()) available.

That would be cool, works well with instances if I'm correct.

Evening all!

Was the render triangles as random colours been removed?

I'm Sketchup based, so displacement maps is always fun ;)

Render as random colours helps me lots to see what the displacement is actually doing.

Can we have it back please.

Or can someone show me where it has moved to please

CADMonkey wrote:Evening all!

Was the render triangles as random colours been removed?

I'm Sketchup based, so displacement maps is always fun

Render as random colours helps me lots to see what the displacement is actually doing.

Can we have it back please.

Or can someone show me where it has moved to please

It's still there in the Indigo UI, just hiding at the bottom of the diffuse material controls.

ahh there you go, My Bad!

Thanks I was using a phong material.

Is a Blender exporter under development?

Displacement and blend shaders can now use posOS(), which returns the object-space position.

This uses an FBM shader based on posOS for the blend factor:

Oscar J wrote:Is a Blender exporter under development?

Hi Oscar,
We will update the Blender exporter soon to support coating and double sided thin materials, maybe this week.

I also sped up subdiv + displacement by about 2x when shaders are used.

OnoSendai wrote:Displacement and blend shaders can now use posOS(), which returns the object-space position.

That will be very handy, thanks a lot!

OnoSendai wrote:I also sped up subdiv + displacement by about 2x when shaders are used.

Oh lovely :)