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??

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
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

Yes, you read right
http://www.indigorenderer.com/joomla/fo ... php?t=4428

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.




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.



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.

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.

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:


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

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.

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.

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.

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.

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?

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

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?

Yes.



Yes, like this:


However this won't work until the next release.

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>

What's the error message that it gives?