Indigo 1.1.10

General News and accouncements regarding the Indigo render engine
User avatar
Whaat
Developer
Posts: 1827
Joined: Fri Dec 22, 2006 6:15 am
Location: Canada
Contact:

Re: Indigo 1.1.10

Post by Whaat » Sun Sep 14, 2008 2:13 pm

OnoSendai wrote:
Whaat wrote:
OnoSendai wrote: EDIT: attached latest manual, which contains documentation for new shader language functions, and emission_scale.
Thanks a bunch! I guess the confusing part for me is that I still don't see anything about efficacy. Is emission scale the same as efficacy scale? What happened to power (watts) and overall luminous efficacy? (lm/W) These are familar terms to many users. All of my emitter presets were based on these values.

How do I create a simple 100W incandescent bulb now? :?
The emission scaling functionality now is basically a superset of the old efficacy scale functionality.

The old way of setting the power drawn (Watts), and overall luminous efficacy (lm/W) was basically a convoluted way of specifying the luminous flux (lm) of the light, which is just the product of the power drawn, and the overall luminous efficacy.

With the new emission scale system, you can just set the luminous flux directly. In addition, you can also scale the emission of the light according to other measures, such as luminance, luminous intensity, and luminous emittance.

To create a 100 W incandescent bulb, using a figure of 13.8 lm/W from wikipedia ( http://en.wikipedia.org/wiki/Luminous_efficacy ), and 100 W, the luminous flux of the bulb is 100 W * 13.8 lm/W = 1380 lm.
It's definitely making more sense. However, the one thing that you still haven't clarified is what happens to base emission when you use emission scale?

For example, if I define base emission value to be RGB spectrum R=1000,G=1000,B=1000, that defines an emitter with spectral radiance in units of W m-3 sr-1. If I then set the emission scale for that material, does Indigo then normalize the RGB values and then set the luminous flux purely from the emission scale value, or do the two values (base emission and emission scale) work together some other way?

Also, what about blackbody spectra defined in base emission value? In the absence of the emission and emission scale parameters, does the spectral radiance value=1? How is the luminous flux calculated in this case?

What I am asking in a round about way is whether you can define a 100W incandescent emitter (say 2800K blackbody) WITHOUT using emission scale.

One last question that I don't think has been addressed: Can you use IES profiles with emitting materials? If so, how??

Big Fan
Posts: 745
Joined: Tue Oct 17, 2006 9:37 am
Location: Nelson NZ

Post by Big Fan » Sun Sep 14, 2008 5:15 pm

I wonder if meshlights should/could stick around for a while/permanently?
and also be incorporated into the layers code?

they are easily accessible/familiar to new and existing users and have easily understood options without thinking in terms of emissive phong ,diffuse or whatever.

this is why I added the new emissive scale stuff as being a 'glowing' material option in my blendigo SW exporter - thinking of it as an added dimension to the material rather than being a 'light'.

perhaps ono can talk briefly about where he sees this going or is taking this.

I think exporter writers still need to interface with ono's code in ways that are meaningful/sensible to render artists and arch/product viz people rather than physics grads/technologists/rendererheads :roll:
Watts are something most people can relate to, spectral radiance or flux is not. I sure most users will not want to be scurrying of to consult tech data all the time
Diving into a phong material to make a light doesnt seem intuitive/logical to me.
Although ono's code is no doubt versatile and empowering I think we need to keep in mind practical use most likely falls into KISS territory - a bit reminiscent of the chlorinated/tropical/arctic water debate..

On IES, I think the purpose of IES profiles is to describe a specific source and light distribution for a particular real world fitting so I dont see that needs to associate with a material of variable nature.
materials relate usually to a large surface area too whereas the IES source is quite small and is defined by a point in space and a direction

my few cents :)

perhaps indigoists who are not export writers should ultimately say how this is presented for use...speak up please 8)

User avatar
Kram1032
Posts: 6649
Joined: Tue Jan 23, 2007 3:55 am
Location: Austria near Vienna

Post by Kram1032 » Sun Sep 14, 2008 11:37 pm


User avatar
OnoSendai
Developer
Posts: 6241
Joined: Sat May 20, 2006 6:16 pm
Location: Wellington, NZ
Contact:

Re: Indigo 1.1.10

Post by OnoSendai » Mon Sep 15, 2008 1:09 am

Whaat wrote:
OnoSendai wrote:
Whaat wrote: Thanks a bunch! I guess the confusing part for me is that I still don't see anything about efficacy. Is emission scale the same as efficacy scale? What happened to power (watts) and overall luminous efficacy? (lm/W) These are familar terms to many users. All of my emitter presets were based on these values.

How do I create a simple 100W incandescent bulb now? :?
The emission scaling functionality now is basically a superset of the old efficacy scale functionality.

The old way of setting the power drawn (Watts), and overall luminous efficacy (lm/W) was basically a convoluted way of specifying the luminous flux (lm) of the light, which is just the product of the power drawn, and the overall luminous efficacy.

With the new emission scale system, you can just set the luminous flux directly. In addition, you can also scale the emission of the light according to other measures, such as luminance, luminous intensity, and luminous emittance.

To create a 100 W incandescent bulb, using a figure of 13.8 lm/W from wikipedia ( http://en.wikipedia.org/wiki/Luminous_efficacy ), and 100 W, the luminous flux of the bulb is 100 W * 13.8 lm/W = 1380 lm.
It's definitely making more sense. However, the one thing that you still haven't clarified is what happens to base emission when you use emission scale?

For example, if I define base emission value to be RGB spectrum R=1000,G=1000,B=1000, that defines an emitter with spectral radiance in units of W m-3 sr-1. If I then set the emission scale for that material, does Indigo then normalize the RGB values and then set the luminous flux purely from the emission scale value, or do the two values (base emission and emission scale) work together some other way?

Also, what about blackbody spectra defined in base emission value? In the absence of the emission and emission scale parameters, does the spectral radiance value=1? How is the luminous flux calculated in this case?

What I am asking in a round about way is whether you can define a 100W incandescent emitter (say 2800K blackbody) WITHOUT using emission scale.

One last question that I don't think has been addressed: Can you use IES profiles with emitting materials? If so, how??
After defining the base_emission and emission of a material, the material will have a certain emission spectrum (spectral power distribution). If an emission_scale element is then defined, then a scaling factor will be applied to the whole spectrum, so that the measure as defined in the emission_scale element has the desired value. So the emission_scale basically acts as a scalar multiplier for the emission spectrum, with the multiplication factor determined by internal Indigo calculations.

Also, what about blackbody spectra defined in base emission value? In the absence of the emission and emission scale parameters, does the spectral radiance value=1? How is the luminous flux calculated in this case?
No, the spectral radiance value is not one. It's determined using Planck's law. The luminous flux of such an emission spectrum is determined in the usual way, by weighting by the luminosity curve.
What I am asking in a round about way is whether you can define a 100W incandescent emitter (say 2800K blackbody) WITHOUT using emission scale.
Sure, just integrate the emitted spectral radiance (as determined by Planck's law) over the hemisphere, over all wavelengths, and over the surface of the emitter, which will give you the total emitted power (100W). Then, assuming your undetermined variable is either the surface area of the light source, or the temperature of the light source, solve for that variable.

User avatar
OnoSendai
Developer
Posts: 6241
Joined: Sat May 20, 2006 6:16 pm
Location: Wellington, NZ
Contact:

Post by OnoSendai » Mon Sep 15, 2008 1:11 am

Big Fan wrote:I wonder if meshlights should/could stick around for a while/permanently?
and also be incorporated into the layers code?

they are easily accessible/familiar to new and existing users and have easily understood options without thinking in terms of emissive phong ,diffuse or whatever.

this is why I added the new emissive scale stuff as being a 'glowing' material option in my blendigo SW exporter - thinking of it as an added dimension to the material rather than being a 'light'.

perhaps ono can talk briefly about where he sees this going or is taking this.

I think exporter writers still need to interface with ono's code in ways that are meaningful/sensible to render artists and arch/product viz people rather than physics grads/technologists/rendererheads :roll:
Watts are something most people can relate to, spectral radiance or flux is not. I sure most users will not want to be scurrying of to consult tech data all the time
Diving into a phong material to make a light doesnt seem intuitive/logical to me.
Although ono's code is no doubt versatile and empowering I think we need to keep in mind practical use most likely falls into KISS territory - a bit reminiscent of the chlorinated/tropical/arctic water debate..

On IES, I think the purpose of IES profiles is to describe a specific source and light distribution for a particular real world fitting so I dont see that needs to associate with a material of variable nature.
materials relate usually to a large surface area too whereas the IES source is quite small and is defined by a point in space and a direction

my few cents :)

perhaps indigoists who are not export writers should ultimately say how this is presented for use...speak up please 8)
Light emitting materials are here to stay. Meshlights are there only for scene file backwards compatibility. Meshlights are in fact converted to emitting materials internally.

Big Fan
Posts: 745
Joined: Tue Oct 17, 2006 9:37 am
Location: Nelson NZ

Post by Big Fan » Mon Sep 15, 2008 9:41 am

No, I dont think you read and took on board what I had to say.

I have incorporated emissive materials but I was asking for meshlights to remain (even if you do convert them yourself inside indigo)

Getting to lights from inside the phong menu for instance doesnt make for a logical UI/workflow

Look at this statement:
Sure, just integrate the emitted spectral radiance (as determined by Planck's law) over the hemisphere, over all wavelengths, and over the surface of the emitter, which will give you the total emitted power (100W). Then, assuming your undetermined variable is either the surface area of the light source, or the temperature of the light source, solve for that variable.
This is techno gobbledegook to most people.
It may be quite true but its far more than people need, or want to know or grapple with.
No matter how accurate this code is it has to be readily useable by the 'public'.

If I make a script available to Blenderheads I want them to be able to use it pretty well straight off cos it makes sense.
Blenderheads are all nationalities and ages.
I dont want to have to spend hours interpreting and translating stuff and answering forum questions for people just to get a simple render out.
Why shouldnt a 14 year old from Chile be able to use this renderer?

Furthermore time is money in the commercial world. People want to load something up and use it directly. People love great render results but they love simplicity as well. KISS wins.

Quite obviously you have a particular interest in the scientific aspect of rendering (which is good cos it makes for high quality results) but you have to think of what the end users need...and I dont want to hear a fob about it being the exporters responsibility to patch together a lot of obscure variables...

You want to sell this renderer..- it has to have a market
Like any successful product you need to tailor it for your customers needs.
This is a fact.
Producing a blue and yellow striped Rolls Royce with a 660cc engine may be personally interesting and satisfying to some manufacturer but its not savvy and wont keep him in work or help people with transport who cant use his produce.

sorry to get on your back but it seems necessary
Last edited by Big Fan on Mon Sep 15, 2008 12:16 pm, edited 2 times in total.

User avatar
pixie
Indigo 100
Posts: 2332
Joined: Sat Dec 29, 2007 4:54 am
Location: Away from paradise
3D Software: Cinema 4D
Contact:

Post by pixie » Mon Sep 15, 2008 9:56 am

Big Fan, but then it's up to you to see what blender's niche is and target it accordingly. After all Indigo should fit well into blender philosophy, it's all a matter of translation.

Big Fan
Posts: 745
Joined: Tue Oct 17, 2006 9:37 am
Location: Nelson NZ

Post by Big Fan » Mon Sep 15, 2008 10:11 am

no excuse me I am not out here to provide a 'product' that targets a niche called Blender and gratus.
I am not here to rehash big chunks of code whenever ono gets the inspiration to do something in a different way.
Please dont get me started on Blender philosophy.
The only reason you have a script now to experiment with 1.1.10 is because of my kindness to do so in smartdens abscence.

How much useful feedback does anyone ever provide other than variants of "it doesnt work"?...even if invited..

Having flux and spect radiance parameters hanging out of emissive materials is not useful.
Accessing lights (as I understand ono's intent to deprecate meshlights) by drilling down inside a material is not useful either.

User avatar
pixie
Indigo 100
Posts: 2332
Joined: Sat Dec 29, 2007 4:54 am
Location: Away from paradise
3D Software: Cinema 4D
Contact:

Post by pixie » Mon Sep 15, 2008 10:21 am

You know your product, and you know how blender works and blender workflows... then there's translation layer between the two languages used by both programs so that bridges can be made, that being said I don't know much of blender but regarding Cindigo I see lot's of cinema own terminology being used, and I think many more should be used so that the (in this case) cinema user just has to learn how to use one program, Cinema.

User avatar
OnoSendai
Developer
Posts: 6241
Joined: Sat May 20, 2006 6:16 pm
Location: Wellington, NZ
Contact:

Post by OnoSendai » Mon Sep 15, 2008 3:45 pm

Big Fan:
Of course ease of use and simplicity is, or should be, an important goal for Indigo, and the exporters for Indigo.

But the fact remains, that emitting materials are a good idea for several reasons:

1) Real materials that emit light tend to reflect light as well. Meshlights have no reflectivity, and hence aren't realistic. Emitting materials may have a non-zero albedo, and hence are more realistic.

2) Emitting materials are useful for modeling certain scenes. For example, BbB had to jump through a few hoops to model his Sci-fi city scene, because he couldn't just make the windows emitters, but had to divide up the buiding meshes into emitting and non-emitting components. This kind of thing isn't necessary with emitting materials.

User avatar
Whaat
Developer
Posts: 1827
Joined: Fri Dec 22, 2006 6:15 am
Location: Canada
Contact:

Post by Whaat » Mon Sep 15, 2008 4:01 pm

so....

if I had a material with base emission RGB: 1000 500 1000 and a material with base emission RGB: 1.0 0.5 1.0 and both materials had emission scale set to 100 lm in a given model, should they render the same? (i.e. same color and brightness)

and...

what about IES in emitting materials??? can it be done yet?

Big Fan
Posts: 745
Joined: Tue Oct 17, 2006 9:37 am
Location: Nelson NZ

Post by Big Fan » Mon Sep 15, 2008 4:05 pm

Ono,
you misunderstand me I think.

I like emissive materials, please leave them in there.I see and appreciate the advantages

but...

I want you to keep the meshlights code cos they are simple and logical

I want to keep meshlights in my UI because RGB, peak etc and W/efficacy are simple and logical for users.
I like it that IES are grouped in there -it s convenient to think about 'lights' that way.

The parameters you have ATM for emissive materials are not simple and logical for techno illiterates

If you had just Watts in there it would be much better IMHO

If you delete the meshlights stuff then we put in front of people phong, spec etc materials and tell them to use it as a light.(?!) worse still they have unusual/unfamiliar 'parameters' to handle that they cant easily relate to, or set as something like 2800k

I hope you see what I am saying :wink:

Perhaps to get around this you/we could set up a generic emissive material to be a 'meshlight'.
That is behind the UI it exports as a simple emissive phong - only one tex- but you can still set peak etc parameters, and, IES is in the same menu?
Last edited by Big Fan on Mon Sep 15, 2008 4:22 pm, edited 1 time in total.

User avatar
OnoSendai
Developer
Posts: 6241
Joined: Sat May 20, 2006 6:16 pm
Location: Wellington, NZ
Contact:

Post by OnoSendai » Mon Sep 15, 2008 4:17 pm

Whaat wrote:so....

if I had a material with base emission RGB: 1000 500 1000 and a material with base emission RGB: 1.0 0.5 1.0 and both materials had emission scale set to 100 lm in a given model, should they render the same? (i.e. same color and brightness)
Yes.
Whaat wrote:
what about IES in emitting materials??? can it be done yet?
Yes, like this:

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>
However this won't work until the next release.

User avatar
F.ip2
Posts: 160
Joined: Thu Aug 10, 2006 11:05 am

Post by F.ip2 » Mon Sep 15, 2008 5:44 pm

Hey Ono

this shader used as an external material makes Indigo crash / quite without any warning.

I is applied to a simple uv unwrapped sphere. Something in particular I do wrong?


<?xml version="1.0" encoding="utf-8" ?>
<scenedata>
<material>
<name>Sphere</name>

<phong>
<exponent>
<constant>10000</constant>
</exponent>
<specular_reflectivity>
<constant>
<uniform>
<value>0.6</value>
</uniform>
</constant>
</specular_reflectivity>

<bump>
<shader>
<shader>
<![CDATA[
def eval() real :
mul(
fbm(
dot(
vec2(300.0, 300.0),
getTexCoords(0)
),
10
),
0.001
)
]]>
</shader>
</shader>
</bump>
</phong>

</material>
</scenedata>
--
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

User avatar
OnoSendai
Developer
Posts: 6241
Joined: Sat May 20, 2006 6:16 pm
Location: Wellington, NZ
Contact:

Post by OnoSendai » Mon Sep 15, 2008 7:04 pm

F.ip2 wrote:Hey Ono

this shader used as an external material makes Indigo crash / quite without any warning.
What's the error message that it gives?

Post Reply
78 posts

Who is online

Users browsing this forum: No registered users and 21 guests