DEV-thread - Blendigo v0.7 - material-editor-exporter

[Kram1032]

ah, you applied the sphere to the boundingbox? great!
Definately a better solution

[DaveC]

I am very pleased to confirm that everything you have updated is working exactly as expected Tried on several differently scaled/applied scaled sphere primitives. All present and correct. Exported mancandy first time with the armature layer still visible.

Excellent work, Zuegs.

[5OnIt]

Thank you DaveC and dmn. With your help I figured it out (for the most part)

[dmn]

Zuegs
I have tiny request:
in the system tab could you place a button 'autoInstance',
and have it trigger a function that searches for identical triangle sets and makes them instanced, with changing transform properties?

I'm guessing the default would be off, because it would probably add to the export time...

[mrCarnivore]

@zuegs: Can you PLEASE enable f-stops with floating point precision? Going from 1 to 2 is a pretty huge increase (double the DOF)...

[zuegs]

@dmn: sorry, i don't realy understand your request why you just don't ALT-D your objects so they get instanced automaticaly???

@mrCarnivore: i will loke on that. I thought it should work by just tapping a value like 3.4 in it? I will investigate that

[dmn]

I have a lot of geometry that comes in from another program, so it is impossible to Alt-D after everything is already modelled. Otherwise I would be alt-ding at every step.

[mrCarnivore]

@dmn: I think your request would have very limited use since almost only you would benefit. More important the change would be far from trivial and therefore not practical, I think!

@zuegs: Every time you type in a floating point number it automatically changes to the nearest integer value. The change shouldn't be that difficult. I would do it myself, but I neither understand your code correctly, yet, nor know too much python...

[Wedge]

I still have not used this exporter yet but I'd like to talk a little about numbers if nobody minds. This should apply to all Blender exporters since it really applies to the code itself.

There are some limitations that Blender exporters will all have as far as I can see. When you put down a number box will a min and max value, you are limited to the number of decimal points you can have. If you use a 100 min and 999 max number you are only allowed one decimal place for another digit. So 100.5 or 546.7 is valid. If your max number is 1000 or above (four digits to the left of decimal point), you are not allowed any decimal points, even if the min number is 10 and you select it. If your max number is only two digits, say anywhere from 10 to 99, you can have two decimal places for more digits. So 50.25 or 10.99 is valid. And of course if your max is 9, you are allowed 3 digits for decimal place. (1.001 or 9.256 is valid)

This problem can be worked around, but a key feature is lost I think. The fix is using a text box with a character limit rather than a number box (with a min and max allowed digit). Problem is now, for new users, they are faced with a plain text box that can take any size number and now they can be confused by not knowing where the 'good range' of numbers that might work are. This could be solved by a tooltip or a printed text message I suppose but now it can get messy. You will also have to error check every text box you use to make sure a number has been entered and not a letter or other unsupported character.

I will be interested to see what happens with the interface when Blender 2.50 comes. Mainly I want to know if any of these limitations (at least that is what I call them) are changed.

It would also be nice if someday Blender is built with Python 2.5 with all official builds. I would like to read some Python documentation on what is new for 2.5 but it would not help much until Blender uses it. Even then since I have not read too much 2.5 documentation I am not sure how much it would help. (new features, speed, stuff like that)

Also, it would be nice to have a boolean that was "false" and "true" rather than "False" and "True." I guess this request is just picky on my part but Indigo does not like "T"rue it only likes "t"rue. There is a boolean in Python but the capital letter makes it useless for Indigo. I do not know who to ask for this request.

Here is the roadmap link for anyone that cares:
http://www.blender.org/development/curr ... since-243/

I did not know I was going to write this much...maybe I should have started a new thread...

Anways, thanks for reading!

[Big Fan]

edited to remove all

[Kram1032]

a multiplier would help, too
btw: I'd like to have a multiplier for any single value in absorbtion and SSS, when it's RGB
For now, I didn't need it, but it was quite hard to find the corect range, where all three values where right

[zuegs]

@kram:
you perfectly described the Number problem in your post. Currently we have some small workarounds for this in Blendigo. All RGB values has an additional "gain" multiplier (also SSS ) and in some other places we have a additional exponent Number Box (ex linear tonemapping has a value and a exponent Number which results in =value*10^exponent).
I like your nice idea about using text boxes to enter numbers... just the validation after input would give some extra code but not to much i think

[Kram1032]

I know, that there is ONE multiplier, but I'd like to have THREE!
one for
Red
one for
Green and
one for
Blue!

(don't forget the size-multiplier, I requested, once )

[zuegs]

I never missed separate multiplier for R, G and B but it's a possibility too. (btw: where you needed this? )

size-multiplier for the whole world coords? I haven't forgot that - once i will put it in sure soon stay tuned

[Kram1032]

I didn't need it, yet, but nearly
I figured out a way how to work around, by calculating a multiplier-value, that gave a propper result.

An other idea:
if you use any neutral grey value (000 111 222 ... 127127127 ... 255255255), that's the same as uniform, right?
If so, can you give away the uniform, and add a checker for uniformal grey values, instead?
Would be more accurate: minimum value would be: 0.0001, now it's 0.1, which isn't low enough, if you want to make fog.

AND if that's possible and you really make three gain-values, you should add a chain-symbol like in photoshop, to let the propotions stay simmilar...

What do you think? Maybe, that's too much already, though...