Indigo 2.4 - Don't Make Me Think

[dougal2]

but we WILL do a naming standardisation.

Fixed.

I don't think anyone would mind which exporter we use as a model for standardization, just as long as it is done.

months and months ago a document was started amongst exporter devs in order to standardise terminology. Looking at our developer resources, I see that document never really made it out of being a draft.
If that doc was completed, I'd have no issue making sure that Blendigo conforms.

[benn]

The google document that Dale did up? Can one you guys post it onto the forum so that we can get feedback from this lot? Just print to pdf or somesuch.

[Soup]

I don't think anyone would mind which exporter we use as a model for standardization, just as long as it is done.

Agreed! That's one thing that's gotten me quite often..
albedo = color;
nkdata = metals;
oren-nayar = ?? (the name still confuses me, I think it should just be an option of diffuse.)

-nkdata metals are named properly and edited to remove the useless ones.

-When saving an IGI have the option to have a PIGI that packs the scene file with it, incase you're using the default scene file, or accidentally change it.

-database function in exporters works like it does in Material Editor: selecting a material downloads it and automatically replaces the currently selected material in the 3d package.

-Add basic materials section to database: includes Lights of varying intensity to reflect normal light bulbs, simple/optimized glass. The materials in SkIndigo's preset list are pretty good for this.

-CPU priority issues: Find a good setting and standardize it. I still am having to use the task manager to manage indigo sometimes. Some exporters set it differently.

I'll add more when I think of them, I've got plenty

[dougal2]

oren-nayar = ?? (the name still confuses me, I think it should just be an option of diffuse.)

This is what I've done in Blendigo 2.5 - added a sigma parameter to diffuse. if sigma == 0 then export diffuse else change the name to oren_nayar and add the sigma. In the exporter, it's always called diffuse and the term "oren_nayar" is not used.
I can't remember if Blendigo 2.4 does this, but I may well back-port this feature.

-Add basic materials section to database: includes Lights of varying intensity to reflect normal light bulbs, simple/optimized glass. The materials in SkIndigo's preset list are pretty good for this.

The next release of Blendigo will include a large set of 'Lamp Spectrum' data that models lots of common (and quite a few uncommon) light types and their colour spectra.

[dougal2]

Here is the Indigo Exporters UI Spec as written by Whaat. Not sure if it's of any use to any ordinary user, but I'd like to know from the other devs if this is finished so that I can make blendigo conform.

[Whaat]

I personally don't this document needs to be posted on the forums. It will only result in a bunch of different opinions large based on the exporter that the user is the most familiar with. WE as developers need to simply make a decision about the correct standarization taking into account the end-user and not our own personal preferences. From our experience on the forums over the past several years, we have a very good idea of what Indigo parameters are confusing to the users.

And no, the document never became more than an initial draft. It is not complete. It needs a thorough review by Glare and all other devs.

[fused]

i think so too. deleted file. sorry doug

[dougal2]

meh, ben's idea. can we take this discussion over to the dev group then ?

[Soup]

The next release of Blendigo will include a large set of 'Lamp Spectrum' data that models lots of common (and quite a few uncommon) light types and their colour spectra.

Sounds like something Indigo should be packaged with, like the IES profiles.

[Godzilla]

Perhaps Indigo could have an alternative dark skin?

[neo0.]

Perhaps Indigo could have an alternative dark skin?

I am actually in agreement with godzilla. I think I'll go call my doctor and check just to be safe.

Anyhow, request, in general is to make the UI more elegant at the same time while making it simpler to use. What does this mean? Well, think about cell phone UIs (such as the Iphone.) Part of what makes them so great is how they use screen real estate by using the same space for multiple things. Here are some examples of how I feel this could be applied to indigo :
○Instead of having two separate buttons for pause/resume render, why not combine them into one, like windows media player does (or any other player) does?
○Instead of the render view just displaying your render, why not use it to give you access to other controls? Instead of having to go up to the top bar to save your image, why not have a panel overlayed on the render view that fades into view when you hover your cursor over it. This panel would let you save your render whatever image type indigo supports.


If you have specified a max number of samples to render to, have a small progress bar with the percent rendered overlayed.

Maybe even allow us to click on certain objects to tell indigo "this is what I want to be in focus."



In general, I think the top bar should be minimal and the side bar should be more "concentrated." For example, if you switch to your resolution settings, there is alot of empty space... With certain things like tonemapping, also, where there are only 3 options ("reinhard", "linear", and "camera") it seems like it would be much faster to just use tabs instead of a drop down.

[Godzilla]

○Instead of having two separate buttons for pause/resume render, why not combine them into one, like windows media player does (or any other player) does?

If you have specified a max number of samples to render to, have a small progress bar with the percent rendered overlayed.


In general, I think the top bar should be minimal and the side bar should be more "concentrated." For example, if you switch to your resolution settings, there is alot of empty space... With certain things like tonemapping, also, where there are only 3 options ("reinhard", "linear", and "camera") it seems like it would be much faster to just use tabs instead of a drop down.

Yes to all of those.. especially the side bar, I've had some ideas on how to better utilize the screen space, I'll try and post up some concepts soon.

○Instead of the render view just displaying your render, why not use it to give you access to other controls? Instead of having to go up to the top bar to save your image, why not have a panel overlayed on the render view that fades into view when you hover your cursor over it. This panel would let you save your render whatever image type indigo supports.


Maybe even allow us to click on certain objects to tell indigo "this is what I want to be in focus."

Don't agree with these. First seems unnecessary, as there is already a huge 'save image button', and the second is impossible without restarting the render.

[neo0.]

True. but with GPU acceleration, rendering general should be pretty fast and, in any, case it's faster than having to stop the render, exit, open up the exporter settings, make, changes, and then restart the render.

IMO, the biggest thing im really going for here is combing UI controls..

[pixie]

Having the layers number as well as their alias bring an unnecessary impedance to the system, having said that, having a slider where user could have a direct feedback would be mostly welcome, as it would IMO if the user had access to the multiple ways indigo uses for light (black body, RGB...) and work in each colorspace, so he might be picking RGB and change the value in that color space or he might chose blackbody and work from there...

[Meelis]

Plz make to indigo render log an button to turn on or off refreshing the log.
It's hard to scroll to right place and read info if it refreshes after soo little interval time and auto scrolls to the end of the log.