Cindigo 0.9 - beta 2

Post by **fused** » Thu Oct 11, 2007 7:25 pm

hmmm... i already know how instances with different materials work. you have to override the old material definition before the instance that should get this material.

CoolColJ wrote:If no material helper is assigned it uses the same material as the referenced object

im not sure if i can get that to work... maybe

Post by **fused** » Fri Oct 12, 2007 1:04 am

i dont know anything about bum/exponent map's abc values. it would be nice if someone would post some good defaults (maybe with a little explanation?)

Zom-B · Post by **Zom-B** » Fri Oct 12, 2007 1:43 am

fused wrote:i dont know anything about bum/exponent map's abc values. it would be nice if someone would post some good defaults (maybe with a little explanation?)

mark just wrote some quick notes to explain abc.

defaults should be for exponent maps a=0, b=same as the exponent of the phong material , c=0
for bump a=0, b=0.001, c=0

b is the basic linear usage and a + c are for advanced use.
Generally for the stuff a + c do, you used Photoshop etc. before to alter your exponent/bump map...

Post by **fused** » Fri Oct 12, 2007 1:52 am

that means for exponent maps i should not let the user choose the b value?

what happens if b > exponent or b < exponent?

Zom-B · Post by **Zom-B** » Fri Oct 12, 2007 2:01 am

fused wrote:that means for exponent maps i should not let the user choose the b value?

what happens if b > exponent or b < exponent?

Hey fused...

If an exponent map is used, the exponent value of the phong material gets ignored. let the user choose all three values.... b is the mostly used, because it reads your map linear.... a pixel with 50% white gets an exponent of 50% of the b value. so using a default of 1000 for b is maybe not enough because only pure white pixels get this 1000 exponent.

Post by **fused** » Fri Oct 12, 2007 2:04 am

thank you!

CoolColJ · Post by **CoolColJ** » Fri Oct 12, 2007 6:37 am

are you sure about that? I thought the exponent value of phong still gets used to set the lowest level, and the exponent map just adds ontop of that

Kram1032 · Post by **Kram1032** » Fri Oct 12, 2007 6:43 am

pure blacks in exponent maps could lead to strange results (I've heard), so, there, the c-value could work just fine

the formula is simple:
x = colour (/ brightness) -value of the original image
y = colour as used in Indigo

ax²+bx+c = y
if you use 0x²+1x+0 = y, you get the image as-is

1x²+0x+0 = y means, your contrast is squared - very dark values get a lot darker, while very bright ones get even brighter
0x²+0x+1 would mean, the *entire* image is uniformly coloured... I'm not sure, *which* colour it has, then. diffuse white, as the normalized RGB values? "1 1 1" grey, in the 0-255 colour range? I've no particular idea.
what I'm sure of, is, that you can't have both a and b 0 at the same time, except you want uniform colours, as both define contrast.

(What I *don't* know, is, in which range the a b and c values are defined... 0-1? 0-255? any extremely different version? - ok, usually, it's 0-1, in Indigo, so, I guess, it's the same thing, here

)

Post by **fused** » Fri Oct 12, 2007 9:00 pm

thank you for the detailed answer, kram!!!

i wont be around the next week, but i did make some progress that i dont want to hide from you!

im sure there are lots of bugs. might be very instable. cant help it. im a coding noob

.obj export is very slow for large meshs and very unoptimized (81 secs for a 500.000 polygon(tris) mesh on my p4 3.0Ghz).

-----------------------------------------------------------------------------

CINDIGO 0.9 - BETA 3 preview

download exporter:
PC Version

(or below)

The file contains PC versions for R10 and R9. (R10 users will have to rename the "cindigo0.9.3.cdl_R10" to "cindigo0.9.3.cdl")

please tell me if you find bugs or have specific requests. i will try to fix/implement as fast as possible.

new in 0.9 - beta 3 preview:

* lots of small improvements (most of them concerning materials, materials in hierarchy, and lots of little things i forgot about, should start keeping a detailed changelog...)
* new .obj export that supports selections and phong breaks (still only UVW mapping)
* export and run (damn useful)
* a,b,c controls for bump maps and exponent maps

fixed-list 0.9 - beta 3 preview:

* crash on instances of lights
* instace scale
* rotation bug and other mesh stuff, normals (finally all bugs, concerning that issue, killed)

known bugs/issues 0.9 - beta 3 preview:

* only UVW-mapping supported

features to come in 0.9 - beta 3(or later): (for preventing double and tripple requests)

* .igm import
* better .obj export (still needs optimization)
* copy textures
* material previews
* some changes for blendmats
- tell me if i forgot sth!

let me know if sth is not working

extraextra: a little baking tutorial

Pinko5 · Post by **Pinko5** » Fri Oct 12, 2007 9:10 pm

Tnx Fused
Pinko.

Marcofly · Post by **Marcofly** » Fri Oct 12, 2007 9:44 pm

Thank you very much, fused!!
you've done a great job!

mrmoose · Post by **mrmoose** » Fri Oct 12, 2007 10:32 pm

Thanks fused for your hard work

One only question: instead of writing your own export routine why don't you use integrated exportation? Cinema has already a function to export object as .obj and convert on the fly parametric objects (Nurbs, Sweep, Loft, Primitives, Array, Boolean...). Furthermore it exports UVMap correctly with the right projection. I don't know if this is possible but I remember BlackLizard plug-in... it exported objects perfectly.

Please let me know if I have told something wrong.

Ciao

Post by **fused** » Fri Oct 12, 2007 11:07 pm

c4d .obj export doesnt export normals

ciccio · Post by **ciccio** » Fri Oct 12, 2007 11:13 pm

Thanks fused for your work

mrmoose · Post by **mrmoose** » Sat Oct 13, 2007 12:47 am

fused wrote:c4d .obj export doesnt export normals

Probably I'm wrong, but i have done a test and it works.
I inserted an object, transformed in editable, reversed some faces and exported in obj format. Then I opened the object and normals were right, the reversed were still reversed. This means that export routine exports normals correctly, isn't it?

But, I repeat, probably I'm wrong.

Cindigo 0.9 - beta 2

Who is online