my 2 ct
Indigo 1.0.1
Big Fan
All these nifty features however are super for the people creating the exporters etc. to use with Indigo. It's up to them to make it real easy for the end user and Ono to provide the more complex feature set for them to tap into enabling them to make it easy.
Your point is right on. I do think it's the developers, of the front end, whether exporter or using the commercial SDK, who need to make it a piece of cake for the end user. Ono's providing the tools for that.
I totally agree that people who do commercial design work just want to be able to render.what is the point of modelling a particular Nikon or Canon camera for instance?
All these nifty features however are super for the people creating the exporters etc. to use with Indigo. It's up to them to make it real easy for the end user and Ono to provide the more complex feature set for them to tap into enabling them to make it easy.
Your point is right on. I do think it's the developers, of the front end, whether exporter or using the commercial SDK, who need to make it a piece of cake for the end user. Ono's providing the tools for that.
well I'm sorry but I think its going in the wrong direction..
really this is ono's project and he takes it where he wants I understand that..
but to my mind this amount of detail is becoming navel gazing
there are other aspects that should be the focus of development attention.
minute technical details about the colour of say tropical sea water versus arctic sea water to my mind is drifting off into pointyheaded pointlessness.
ok so I dont make exporter or other contributions any more so the point is just for nattering but I really dont see why I would make a GUI completely full of buttons options and variables just cos ono makes it available.
trying to get sensible answers out of ono about some aspects is a mission in itself...
somewhere along the way someone has to make a judgement call about the worth of some of this stuff - commendibly accurate or not.
If it is up to exporter writers to reinterpret the work then people are going to get upset because so and so left something out or interpreted it differently
I guess this situation has already happened to some extent with what I did with camera focus and sss/abs.
In the end exporter writers end up wasting their time producing divergent code...or just throwing everything available in there...which has to be even more confusing to newbies ( even if they had an up to date wiki )
really this is ono's project and he takes it where he wants I understand that..
but to my mind this amount of detail is becoming navel gazing
there are other aspects that should be the focus of development attention.
minute technical details about the colour of say tropical sea water versus arctic sea water to my mind is drifting off into pointyheaded pointlessness.
ok so I dont make exporter or other contributions any more so the point is just for nattering but I really dont see why I would make a GUI completely full of buttons options and variables just cos ono makes it available.
trying to get sensible answers out of ono about some aspects is a mission in itself...
somewhere along the way someone has to make a judgement call about the worth of some of this stuff - commendibly accurate or not.
If it is up to exporter writers to reinterpret the work then people are going to get upset because so and so left something out or interpreted it differently
I guess this situation has already happened to some extent with what I did with camera focus and sss/abs.
In the end exporter writers end up wasting their time producing divergent code...or just throwing everything available in there...which has to be even more confusing to newbies ( even if they had an up to date wiki
)Sorry maybe I came across wrong.
I totally agree with your point.
From an exporter writers perspective I will try to recreate an image I take with my digital camera, figuring out what all the code would be to recreate the scene the same. The options I will make available to the user will be what you'd expect on a real camera. I'll have an option for a simple point and shoot camera and one with some additional options. I have the flexibility in the coding because of Ono's options but it doesn't need to be brought out to the user.
Other examples are for Chrome, copper, steel, etc. Simple selections for a user but behind the scenes options and NK data a user doesn't necessarily need to see. Glass, plexi-glass, water all similar. Designers don't want to look up what the IOR is they just want the right material. But ono has to give all the options for the interface coders to use. He's writing the engine more so than the final implementation. Mind you, more advanced options could be made accessible for those who might want to mess with them through an advanced tab.
With Ono releasing a commercial SDK shows he does want Indigo to be more than a little freeware program, helping people make cool pictures. It would be expected that this great engine will become the heart of other bigger projects. I think it also shows he wants to compete and win against the other commercial products.
I think we're on the same path just looking from different directions.
I totally agree with your point.
From an exporter writers perspective I will try to recreate an image I take with my digital camera, figuring out what all the code would be to recreate the scene the same. The options I will make available to the user will be what you'd expect on a real camera. I'll have an option for a simple point and shoot camera and one with some additional options. I have the flexibility in the coding because of Ono's options but it doesn't need to be brought out to the user.
Other examples are for Chrome, copper, steel, etc. Simple selections for a user but behind the scenes options and NK data a user doesn't necessarily need to see. Glass, plexi-glass, water all similar. Designers don't want to look up what the IOR is they just want the right material. But ono has to give all the options for the interface coders to use. He's writing the engine more so than the final implementation. Mind you, more advanced options could be made accessible for those who might want to mess with them through an advanced tab.
With Ono releasing a commercial SDK shows he does want Indigo to be more than a little freeware program, helping people make cool pictures. It would be expected that this great engine will become the heart of other bigger projects. I think it also shows he wants to compete and win against the other commercial products.
I think we're on the same path just looking from different directions.
I agree with jeffr. It's not as if Ono is replacing old simple options with new complex ones. The new complex ones are simply options that are available if you want to use them.
For instance there is nothing stopping you from modeling a diamond and giving it a specular material with an ior around 2.4 but what you get isnt going to look at all like a diamond. More detailed data is required to achieve the actual effect of a diamond. Diamond is a good example because if you don't have the data correct even if you are using complex information it still won't look right at all. Precision is required.
Modeling a window for your house model however does not 'need' the extra precision.
It's all about flexibility.
On the subject of water. Have you seen the difference between simple data water and complex data water?? The former is quite simply unsatisfactory for anything other than a cup of water whereas the latter is what one would expect at larger scales. That's pretty important to me.
For instance there is nothing stopping you from modeling a diamond and giving it a specular material with an ior around 2.4 but what you get isnt going to look at all like a diamond. More detailed data is required to achieve the actual effect of a diamond. Diamond is a good example because if you don't have the data correct even if you are using complex information it still won't look right at all. Precision is required.
Modeling a window for your house model however does not 'need' the extra precision.
It's all about flexibility.
On the subject of water. Have you seen the difference between simple data water and complex data water?? The former is quite simply unsatisfactory for anything other than a cup of water whereas the latter is what one would expect at larger scales. That's pretty important to me.
"A foolish consistency is the hobgoblin of little minds..." - Emerson 1841>Have you seen the difference....
ok if you say so..
personally I dont think I would ever have the need to render 'water' to that level of detail...have you guys considered chlorine levels and dissolved minerals ? seriously...I mean a good generic 'water' for swimming pools etc for architectural renders is quite good enough as far as I am concerned. and besides the house would be the subject not the water...
sorry I still hold by my view that for most users things are getting bogged in unnecessary technical complexity
ok if you say so..
personally I dont think I would ever have the need to render 'water' to that level of detail...have you guys considered chlorine levels and dissolved minerals ? seriously...I mean a good generic 'water' for swimming pools etc for architectural renders is quite good enough as far as I am concerned.
and besides the house would be the subject not the water...sorry I still hold by my view that for most users things are getting bogged in unnecessary technical complexity
0.4E-06 means 0.4 * 10 to the power of -6,CoolColJ wrote:<start_wavelength>0.4E-06</start_wavelength>
<end_wavelength>0.7E-06</end_wavelength>
how do you read these wavelengths?
What would 350nm to 750nm be in these values?
i.e. 0.0000004.
The units are metres, as I generally try to make all units in Indigo base SI units.
So 0.4E-06 is 0.4 micrometres, or 400nm.
350nm is 0.35E-06
Big Fan:
I agree that it's not ideal that you might need to study physics in order to use Indigo, well at least to be able to hack the .igs directly.
But as JeffR pointed out, a good exporter should be able to layer over this complexity.
You make think stuff like regular tabulated spectra is overkill, but I would argue that it's essential for full accuracy and realism. Real spectra have shapes that aren't capturable with just the 3 RGB parameters.
And if at the end of the day, you can just select a material like 'Pure water' from a drop down box, and it will be pretty much fully accurate, I think that's pretty cool
I agree that it's not ideal that you might need to study physics in order to use Indigo, well at least to be able to hack the .igs directly.
But as JeffR pointed out, a good exporter should be able to layer over this complexity.
You make think stuff like regular tabulated spectra is overkill, but I would argue that it's essential for full accuracy and realism. Real spectra have shapes that aren't capturable with just the 3 RGB parameters.
And if at the end of the day, you can just select a material like 'Pure water' from a drop down box, and it will be pretty much fully accurate, I think that's pretty cool
Who is online
Users browsing this forum: No registered users and 34 guests