Hmm, don't use textures in base_emission, put them in emissionWhaat wrote:I get this error message when i try to apply a texture to <base_emission>
Non-textured emitters (constants) are working so far.
Indigo 1.1.7
Oops, textures on blend materials are pretty much completely busted. Wait for the next release and I'll fix that.BbB wrote: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.
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]})
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]})
Yes i know, my spelling sucks
-
- Posts: 1828
- Joined: Mon Sep 04, 2006 3:33 pm
ok...so this is this is bug or what? the updated manual implies that base_emission can take a constant, texture, or shader.OnoSendai wrote:Hmm, don't use textures in base_emission, put them in emissionWhaat wrote:I get this error message when i try to apply a texture to <base_emission>
Non-textured emitters (constants) are working so far.
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.
-
- Posts: 512
- Joined: Wed May 02, 2007 11:34 am
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.
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.
Base emission is a bit of a special case, I guess, and currently only accepts the 'constant' type child element.Whaat wrote:ok...so this is this is bug or what? the updated manual implies that base_emission can take a constant, texture, or shader.OnoSendai wrote:Hmm, don't use textures in base_emission, put them in emissionWhaat wrote:I get this error message when i try to apply a texture to <base_emission>
Non-textured emitters (constants) are working so far.
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.
Oren-Nayar Sigma parameter should be able to take a constant, texture of shader, yes.
Yes, that's correct, dscs315 is the only response function used currently.FakeShamus wrote: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.
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.
Thanks for the response.OnoSendai wrote:
Base emission is a bit of a special case, I guess, and currently only accepts the 'constant' type child element.
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.
Whaat wrote: 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
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...Whaat wrote: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?Fatal Error: IndigoDriverExcep: SceneLoaderExcep: Found unexpected element 'texture' in element 'phong'. (Around line 106, column 17)
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.
Re: Crazy Fireflies!
That looks exactly like the problems I am having!Phoenix wrote:I run the "dispersion_test" from the testscenes and here is the result!
Re: Crazy Fireflies!
It's normal behaviour with Metropolis sampling turned off.Deus wrote:That looks exactly like the problems I am having!Phoenix wrote:I run the "dispersion_test" from the testscenes and here is the result!
Who is online
Users browsing this forum: No registered users and 18 guests