+1BbB wrote:Ono: Would it be possible to also assign the sun, environment maps and normal mesh emitters to different layers? Right now only diffuse emitters seem to accept this.
Indigo 1.1.7
The base emission has high values because in standard SI units, common spectral radiances are large values.suvakas wrote:Hey Ono, can you explain the ways of "base_emission" and "emission" a bit more than in manual?
Why the "base_emission" has so high values like 2000000000 ?? and how the "emission" relates to it?
emission simply multiplies the base_emission.
Crazy Fireflies!
I run the "dispersion_test" from the testscenes and here is the result!
- Attachments
-
- "dispersion_test.igs" with "aperture diffraction" disabled
- dispersion_test-aperture_diffraction_disabled.png (232.16 KiB) Viewed 4455 times
-
- "dispersion_test.igs" with "aperture diffraction" enabled
- dispersion_test-aperture_diffraction_enabled.png (220.82 KiB) Viewed 4454 times
if indigo can still read in old materials from the db, should it not be fairly trival to make it spit the material back out in a new updated format? Then you can just add support in the mdb for different versions of the same matterial (indigo:1.1.5 or ingido:1.1.7 ect).
Yes i know, my spelling sucks
I think that this would definitely be a good feature to add to Indigo, if possible.OnoSendai wrote: No, you can't 'call' other material types from a material shader.
<mr Burns voice>OnoSendai wrote:You can use a shader to control the blend factor of a blend material, however.
Excellent!!
</mr Burns voice>
It would be more of a time-saving device. You could have a scene with maybe hundreds of mesh's, each with their own textures, and then modify those textures in a specific way all at once. An example might be with a dust shader, so you could have a colorful ball, a nicnak, and a book on a shelf all covered in the same dust material. Maybe one way of doing it would be to have material inheritance so that a mesh could inherit a material and then add to it or modify it? But then you might have issues with the order in which the material is added to the object?OnoSendai wrote:not sure why you would want to do that.
The more I think about it, the more I'm thinking that for a dust shader or even a snow shader, you would want to have a separate mesh that is inside the original mesh. In this way I think it would be easier and have better results then trying to modify the original mesh. Especially when using displacement and SSS for the dust/snow.
Grimm
-
- Posts: 289
- Joined: Wed Apr 18, 2007 1:52 am
- Location: Odense, Denmark
What about 'emission_scale' in the <model>OnoSendai wrote:The base emission has high values because in standard SI units, common spectral radiances are large values.suvakas wrote:Hey Ono, can you explain the ways of "base_emission" and "emission" a bit more than in manual?
Why the "base_emission" has so high values like 2000000000 ?? and how the "emission" relates to it?
emission simply multiplies the base_emission.
Do we really need another emission parameter? (it appears to be optional anyway)
I get this error message when i try to apply a texture to <base_emission>
Non-textured emitters (constants) are working so far.
Non-textured emitters (constants) are working so far.
- Attachments
-
- Clipboard01.jpg (10.12 KiB) Viewed 4221 times
-
- default-settings.igs
- materials only - no meshes
- (3.84 KiB) Downloaded 255 times
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.
- Attachments
-
- default-settings.igs
- no meshes
- (4.38 KiB) Downloaded 231 times
yeah I seem to be having trouble with phong too but here it doesnt like 'diffuse_albedo' EDIT: fixed that one
finally worked out the correct way for sigma though
luminance is in but I havent tried it - so much work
finally worked out the correct way for sigma though
luminance is in but I havent tried it - so much work
Last edited by Big Fan on Thu Jul 24, 2008 7:35 pm, edited 2 times in total.
Yes something like that could be an option for converting the entire MatDB. But such a conversion seems kinda pointless if backwards compatibility existseman7613 wrote:if indigo can still read in old materials from the db, should it not be fairly trival to make it spit the material back out in a new updated format? Then you can just add support in the mdb for different versions of the same matterial (indigo:1.1.5 or ingido:1.1.7 ect).
Who is online
Users browsing this forum: Ahrefs [Bot] and 53 guests