Cindigo 1.0.9

[fused]

uploaded the new version, not sure, but there may be bugs with relative paths.

[pixie]

still, im not convinced. using the standard render output path? and export all cameras everytime? (if i get you right) doesnt make much sense to me, the user should have the contol about it.

If user uses the stage object is a clear sign he's using and organizing a scene with a clear and structured organization. Cinema manages scenes in a given way why not use it altogether instead of reinventing the wheel? New users would feel more at home and old user wouldn't have to do things differently weather they are using indigo or cinema.

When you export and give the project a name it saves the camera being used, it might as well save them all, it wouldn't take the user any control just the hassle of naming it (which could be made by key's time or by cameras name easing the scene organization). When I talk on using render output path I do it so that the same data doesn't have to be written twice, after all what you want is the output scene, why bother if it's Cinema or Indigo rendering?

also, when i export and run, wich one gets started? all? and what happens, when i want to export an animation? (when animation support is ready).

Well both my examples and the way stage object works rely on animation so there's no way to avoid it, as for which one who would get started? Being multiple scenes I would go for (a) none whatsoever, akin to what currently the default procedure of cindigo exporter (b) if a limit is given do it batch mode. b) seems the sensible option in an animation, (a) if all cameras are indeed different from each other.

[fused]

hmmm... you convinced me. kind of.

the solution of yours is complicated and because cindigo doesnt support animation for now, i will put it in the camera tag - for now.


@all:

in case you didnt know: if you check "start as network master" in the export dialog, cindigo copies all textures to a sub-dir called textures.*scene-name* and the uses them.

[pixie]

Since animationa isn't yet working it would a be a bit difficult to implement, but once the framework is built I guess it will get a major bump on functionality, for once one could automate a lot.

[fused]

I uploaded a new version. new features/fixes:

* added german translation
* support for -o parameter (in the camera tag under "output")
* fixed blend material issues with blend maps

if you want to blend to a null mat, just leave on of the materials empty.

[pixie]

Some problems I stumbled on:

Indigo scene exported output:

Code: Select all

    <material>
        <name>bb</name>
        <blend>
            <a_name>Mat</a_name>
            <b_name>Trans</b_name>
            <blend_map>
                <uv_set>default</uv_set>
                <path>boingmask.png</path>
                <exponent>1</exponent>
            </blend_map>
        </blend>
    </material>

Exported IGM output:

Code: Select all

    <material>
        <name>bb</name>
        <blend>
            <a_name>Mat</a_name>
            <b_name>Trans</b_name>
            <blend_map>
                <uv_set>default</uv_set>
                <path></path>
                <exponent>1</exponent>
            </blend_map>
        </blend>
    </material>

Both lacking the blend factor and in second case also the path.

[fused]

blend factor fixed.

the second one is strange...

having a look at it right now. upload soon.

[fused]

fixed and uploaded

[WLAD]

cool somthing to play with

[PureSpider]

Got another bug...
When you have a "not C4D" material (fry or vray) in the mat manager and try to convert the mats for indigo C4D crashes
just ignore the materials that are not C4D ones while converting the mats?

[pixie]

If I'm not mistaken it happens also with sky textures..

[fused]

ill have a look at it.

[fused]

found it, think i fixed it. wil be fixed in the next update.

[fused]

updated, should not crash on non-standard materials. some other small fixes, maybe you notice

[fused]

hey,
here's a little preview of whats coming: