Indigo 1.1.10
as a user coming to Indigo from a Arch Viz. background, not a math background or anything like that, what attracted me to this program was the simplicity and"real-world" 1 to 1 way of setting up a render.
ie, 30watt light is a 30 watt light (it matters nothing to me what happens in the background) a big tip of the hat to Whaat for creating Skindigo in this way.
What worries me is if it gets too complicated on the Indigo side, Whaat (and other exporter writers) might not want to keep up with it. I know that this is Onosendai's prerogative, but from a simple users perspective,
KISS rules.
if I have to start doing math calcs, like in the above discussion about how to create an emitter (light to me) than I'll have to move to another renderer,
and I really don't want to do that
ie, 30watt light is a 30 watt light (it matters nothing to me what happens in the background) a big tip of the hat to Whaat for creating Skindigo in this way.
What worries me is if it gets too complicated on the Indigo side, Whaat (and other exporter writers) might not want to keep up with it. I know that this is Onosendai's prerogative, but from a simple users perspective,
KISS rules.
if I have to start doing math calcs, like in the above discussion about how to create an emitter (light to me) than I'll have to move to another renderer,
and I really don't want to do that
there are a number of us here with programing experiance, if one of the exporters was falling behind and there was enough people one of us would probably help out.
also, for more complex stuff you can either save it to the material db so everyone can use it again.
some things just cant be made simple on the other hand.
also, for more complex stuff you can either save it to the material db so everyone can use it again.
some things just cant be made simple on the other hand.
Yes i know, my spelling sucks
cpfresh
are you using Blender? I am not sure if it might be related to UV.
While no UV error came - BigDad mentioned it as a possibility.
However in my scene the things I perfectly unwrapped.
Not even sure if this procedural shader actually needs any UV unwrapping.
I am curious if it could be related to the script exporter.
Claas
are you using Blender? I am not sure if it might be related to UV.
While no UV error came - BigDad mentioned it as a possibility.
However in my scene the things I perfectly unwrapped.
Not even sure if this procedural shader actually needs any UV unwrapping.
I am curious if it could be related to the script exporter.
Claas
--
C l a a s E i c k e K u h n e n
Artist : Designer : Educator
Assistant Professor Industrial Design
Kendall College of Art and Design
of Ferris State University
C l a a s E i c k e K u h n e n
Artist : Designer : Educator
Assistant Professor Industrial Design
Kendall College of Art and Design
of Ferris State University
-
- Posts: 1828
- Joined: Mon Sep 04, 2006 3:33 pm
hey! how about dem asymmetrical IES profiles? linear ones?OnoSendai wrote:Yes, like this:Whaat wrote:
what about IES in emitting materials??? can it be done yet?However this won't work until the next release.Code: Select all
<model> <rotation> <matrix> 1 0 0 0 1 0 0 0 1 </matrix> </rotation> <pos>0 0 0.1</pos> <scale>0.1</scale> <mesh_name>mesh1</mesh_name> <ies_profile> <material_name>mat1</material_name> <path>C:/programming/models/IES/40_planning_luminaire_cn/ies/_family/en/erco_ies_en_CL_downlights_409/ERCO_85263000_2xTC-DEL_26W.ies</path> </ies_profile> </model>
well when you had the same problem from sketchup
I think that the problem is than more related to Indigo.
In particular when it crashed without a warning text.
I would say it closely rules out the exporter or mesh.
Claas
I think that the problem is than more related to Indigo.
In particular when it crashed without a warning text.
I would say it closely rules out the exporter or mesh.
Claas
--
C l a a s E i c k e K u h n e n
Artist : Designer : Educator
Assistant Professor Industrial Design
Kendall College of Art and Design
of Ferris State University
C l a a s E i c k e K u h n e n
Artist : Designer : Educator
Assistant Professor Industrial Design
Kendall College of Art and Design
of Ferris State University
@Claas, before this problem appears in every forum,
I can tell you Indigo crashes if there is a shader referring to co-ords (in particular the uv's it needs) and there are none.
Ono needs an exception error for this.
Open your .igs in Notepad and check to see if the uv's are in there.
If they are not that is very likely the problem.
I suggest you make a simple scene using the bump shader as I provided it, cos I know it works, and export it.
Hand edit the .igs each time to change the values for your very important quality experiments.
Open the Indigo UI manually by double clicking on the .exe and select and run your .igs
I can tell you Indigo crashes if there is a shader referring to co-ords (in particular the uv's it needs) and there are none.
Ono needs an exception error for this.
Open your .igs in Notepad and check to see if the uv's are in there.
If they are not that is very likely the problem.
I suggest you make a simple scene using the bump shader as I provided it, cos I know it works, and export it.
Hand edit the .igs each time to change the values for your very important quality experiments.
Open the Indigo UI manually by double clicking on the .exe and select and run your .igs
Hi Class,
as Big Fan says, I think the problem is that the shader is trying to use uv coordinates that aren't set for the mesh / sphere. I'm catching the error now and printing out an error message instead of crashing, which will be in next version.
Regarding setting the power (Wattage) of an emitter directly, there's what I consider a compelling reason why I haven't added Power as one of the supported measures.
To calculate the total power emitted by an emitter, you need to know the spectral power distribution at all wavelengths, not just those wavelengths inside the visible part of the spectrum. This information is not generally known or required when defining an emission spectrum in Indigo.
as Big Fan says, I think the problem is that the shader is trying to use uv coordinates that aren't set for the mesh / sphere. I'm catching the error now and printing out an error message instead of crashing, which will be in next version.
Regarding setting the power (Wattage) of an emitter directly, there's what I consider a compelling reason why I haven't added Power as one of the supported measures.
To calculate the total power emitted by an emitter, you need to know the spectral power distribution at all wavelengths, not just those wavelengths inside the visible part of the spectrum. This information is not generally known or required when defining an emission spectrum in Indigo.
ono I am not really convinced by your 'compelling reason'
you already have flux hanging out of emission which you have written is actually watts x luminous efficiency
I could do a wee wangle there in the UI and present flux as efficacy scale input and multiple the 2 parameters together under the skin to give flux...
I have thought about this useablility and what I would like to do is to keep my UI the way I have it for emission being an extra dimension for a material (ie simple glow - no IES access there), but also keep 'meshlights' (or simply 'lights') in the mats menu (actually as a mat under the skin but with reversed emphasis.)
ie meshlights will appear not unlike present with IES but there will be a simple menu at the bottom to choose a generic material type for reflectivity of the light source/mesh
so in other words they will actually reference the same things but in a different order/way.
seems to me there are many cases where the light source doesnt need to be thought of as a material or with all the trappings and options of one.
I guess its just a matter of logical/intuitive presentation to the user
if you convert the present meshlights stuff internally is it not possible to keep the parameters for that hanging out of the code for us to retain 'peak' , 'blackbody' etc?
of course other script writers may have other ideas and seeing as how I am on the outside of things here ordinarily my opinion is not so important... still I'll persist with this enquiry in the meantime
you already have flux hanging out of emission which you have written is actually watts x luminous efficiency
I could do a wee wangle there in the UI and present flux as efficacy scale input and multiple the 2 parameters together under the skin to give flux...
I have thought about this useablility and what I would like to do is to keep my UI the way I have it for emission being an extra dimension for a material (ie simple glow - no IES access there), but also keep 'meshlights' (or simply 'lights') in the mats menu (actually as a mat under the skin but with reversed emphasis.)
ie meshlights will appear not unlike present with IES but there will be a simple menu at the bottom to choose a generic material type for reflectivity of the light source/mesh
so in other words they will actually reference the same things but in a different order/way.
seems to me there are many cases where the light source doesnt need to be thought of as a material or with all the trappings and options of one.
I guess its just a matter of logical/intuitive presentation to the user
if you convert the present meshlights stuff internally is it not possible to keep the parameters for that hanging out of the code for us to retain 'peak' , 'blackbody' etc?
of course other script writers may have other ideas and seeing as how I am on the outside of things here ordinarily my opinion is not so important... still I'll persist with this enquiry in the meantime
Who is online
Users browsing this forum: No registered users and 44 guests