Indigo 1.1.7

[OnoSendai]

I get this error message when i try to apply a texture to <base_emission>
Non-textured emitters (constants) are working so far.

Hmm, don't use textures in base_emission, put them in emission

[OnoSendai]

Ok, now things are working when blending the diffuse emitting mat with another, untextured, non-emitting diffuse mat or phong mat...

Indigo crashes when trying to merge a phong with bump or exponent map and a diffuse emitter.

Works nicely by merging a diffuse emitter and a specular.

One weird thing: When I assign the sphere emitter to layer 2, it ends up in layer 0. The other emitters in layer 1 are indeed in layer 1.

Oops, textures on blend materials are pretty much completely busted. Wait for the next release and I'll fix that.

[eman7613]

my, what a string of responses! while it may seem irrelevant now, perhapse something you do in the furture will make maintaining backwards compatibility difficult or imposable? But then again i do not have ono's sacred code

thanks you! (if only women were fun, free, and came with a simple interface that got updated when something was wrong! my life would be so much easier!{no offense or sexism meant[this must be proof insomnia is horrible for me]})

[StompinTom]

(if only women were fun, free, and came with a simple interface that got updated when something was wrong! my life would be so much easier!

quoted for truth. enough said.

[Whaat]

I get this error message when i try to apply a texture to <base_emission>
Non-textured emitters (constants) are working so far.

Hmm, don't use textures in base_emission, put them in emission

ok...so this is this is bug or what? the updated manual implies that base_emission can take a constant, texture, or shader.

It also implies that the sigma parameter can take a constant, texture or shader.

So my question is this (with respect to the several discrepancies in the updated manual):
Do you intend to fix the manual to match indigo or fix indigo to match the manual?? There's a lot of significant changes here and I don't want to re-write the exporter until it's clear exactly how the new scene file format works. Otherwise, I'll be doing it twice.

[FakeShamus]

I have a question about the new tone mapping controls when using camera tone mapping and different camera response functions. it seems when you touch the iso or ev adjust, indigo defaults back to the dscs315 - is this the case? if so, would it possible to adapt the controls to work with different response functions too?

I was also wondering if there is a way to convert the x and y white point adjustments that you make with the new sliders into values that your scene file can match. say I make a slight adjustment to the x and y white point controls during smaller test renders and then I want to set up my scene file to render really large with the console version. is there a white-point syntax besides the presets (D50/D65/etc...) that corresponds to these sliders? I mean, I have photoshop too, but the consistency would be nice.

[OnoSendai]

I get this error message when i try to apply a texture to <base_emission>
Non-textured emitters (constants) are working so far.

Hmm, don't use textures in base_emission, put them in emission

ok...so this is this is bug or what? the updated manual implies that base_emission can take a constant, texture, or shader.

It also implies that the sigma parameter can take a constant, texture or shader.

So my question is this (with respect to the several discrepancies in the updated manual):
Do you intend to fix the manual to match indigo or fix indigo to match the manual?? There's a lot of significant changes here and I don't want to re-write the exporter until it's clear exactly how the new scene file format works. Otherwise, I'll be doing it twice.

Base emission is a bit of a special case, I guess, and currently only accepts the 'constant' type child element.

Oren-Nayar Sigma parameter should be able to take a constant, texture of shader, yes.

[OnoSendai]

I have a question about the new tone mapping controls when using camera tone mapping and different camera response functions. it seems when you touch the iso or ev adjust, indigo defaults back to the dscs315 - is this the case? if so, would it possible to adapt the controls to work with different response functions too?

I was also wondering if there is a way to convert the x and y white point adjustments that you make with the new sliders into values that your scene file can match. say I make a slight adjustment to the x and y white point controls during smaller test renders and then I want to set up my scene file to render really large with the console version. is there a white-point syntax besides the presets (D50/D65/etc...) that corresponds to these sliders? I mean, I have photoshop too, but the consistency would be nice.

Yes, that's correct, dscs315 is the only response function used currently.

In general I'm avoiding saving changes made during interactive tone mapping back into the scene file. But you're right, it should be possible to set the whitepoint values directly in the scene file, instead of just the white balance identifier.

[Whaat]

Base emission is a bit of a special case, I guess, and currently only accepts the 'constant' type child element.

Thanks for the response.

Can you help us all out by listing all of the 'special cases' (i.e. properties that cannot be controlled by textures or shaders?)

Here are the ones that come to my mind:
1) base emission
2) ior
3) media properties (sss, absorption, hg, phase function, etc.)
4) fresnel scale (is this deprecated??)

Please confirm.

Another question: What happens with <fbm>? Is this abandoned now that we have the shader system?

Thanks.

[OnoSendai]

Can you help us all out by listing all of the 'special cases' (i.e. properties that cannot be controlled by textures or shaders?)

Here are the ones that come to my mind:
1) base emission
2) ior
3) media properties (sss, absorption, hg, phase function, etc.)
4) fresnel scale (is this deprecated??)

Well, you can figure it out from the manual.
Stuff like ior has a type of scalar real, where as displacement etc.. have a type of 'wavelength-independent material parameter', which means they can be a constant, texture-driven, or shader-driven.

Make sure you check out pg. 70 in the manual, on wavelength-dependent material parameters etc..

Media properties will be generalised to allow control by shaders at some later stage.

Fresnel scale is still accepted in the scene file, not sure it if does anything any more tho

[OnoSendai]

What happens with <fbm>? Is this abandoned now that we have the shader system?

I think it's still accepted, but it's basically superseded by the shader system, yeah.

[Whaat]

Fatal Error: IndigoDriverExcep: SceneLoaderExcep: Found unexpected element 'texture' in element 'phong'. (Around line 106, column 17)

What's the deal with the new way to specify textures? (i.e. texture indices). I got it to work with diffuse materials but I get the above error with Phong materials. Does this new format only work with diffuse materials?

EDIT: Same error message with oren-nayar materials as well.

That's a bug which I've fixed in my code now. It should work for Phong and Oren-Nayar in the same way as with diffuse.

haha...i was about to ask about this one again and I see you edited my post with the answer. i think you need more sleep, man...

[OnoSendai]

haha, woops, the quote and edit buttons are right besides each other.

[Deus]

I run the "dispersion_test" from the testscenes and here is the result!

That looks exactly like the problems I am having!

[OnoSendai]

I run the "dispersion_test" from the testscenes and here is the result!

That looks exactly like the problems I am having!

It's normal behaviour with Metropolis sampling turned off.