Indigo 0.7 test 7

[zsouthboy]

Basically BiDir is better for everything.

I did some tests and it seems, that Bidir is bad for exr lit scenes and interior scenes where the only light source is the sun. In other areas Bidir should be better.

I should've been more specific.

In general, Bidirectional Path Tracing is more efficient than simple path tracing.

I do have no control over Indigo, though

[suvakas]

In general, Bidirectional Path Tracing is more efficient than simple path tracing.

I do have no control over Indigo, though

Gotcha! Good point.

[Pinko5]

Tnx
Pinko.

[F.ip2]

mhx, my tea pot scene was rendered with mtl one time and than with mtl and BiDir.

The speed is the same - the result 99 the same. BiDir is slightly brighter.

Am I missing something?


edit:
looks like normal smoothing different. The bended mesh as a backdrops is rendered without smoothing interpolation.

[Kram1032]

BiDir should go faster, but the final result should look simmilar
It just depends, WHAT appears WHEN:
Caustics and shadows are much faster noisefree (= bighter?)

[afecelis]

Wow Ono! this version is awesome! Love the new UI library (thinking of crossing over to Linux? (I mean, natively, non-wine)).

What's this new .jgs format? What are the advantages over xml? Is resuming supported via the GUI?

Thanks for all your work Ono!

regards,
Alvaro

[joegiampaoli]

Hi afecelis, the igs is just standard xml code, I exported my preview test scene for blendigo for example just by changing the .xml extension to .igs and it exports the preview test scene perfectly, so I guess it's just an extension rename.

[Discoman]

In "About..." it still refers to itself as indigo v7 test6

[8bstudio]

I'm very happy for super new version! Great Ono!
Now I'll test it!!!

[GustavTheMushroom]

Hi Ono,
I just had some thoughts on the render farming stuff in indigo.
Could you build it into the gui? I mean for instance, you cold connect all the render "nodes" before you start the render, and then tell it which file to render and it will transfer the files (In Sc Files including textures etc) to all of the render nodes and they will start up once they have received the files?

Seems like it would be easier to start renders like this, you could run indigo on startup so all you'd need to do is to start a machine up and it'd be ready to go. You shouldnt have to tell it to do anything because all the data will be transfered. Indigo could just be permanently listening on some port so it could detect a render....


Please tell me this makes sense lol. Im not too good with telling other people about my ideas....

[GustavTheMushroom]

Oh I forgot to mention how I thought the "connecting" would work... you'd just have to tell the "main" indigo what machines the renderers are and because indigo will already be listening it shouldnt be an issue should it? some sort of fail safe would need to be there in case not all of the render machines have been switched on etc etc.

I realise that what im talking about works in complete reverse to how it currently works.... Is there a reason it works the way it does at the moment?

To me this sounds complicated, granted, but i think in the long term it would be good to have a system like this. It just takes so long if you constantly have to go to each machine and start a renderer and transfer the files yourself etc etc etc...

Just some other ideas within this one:

*Some sort of version checking on the files (ie a checksum) to see if the files on the both central and node indigo are the same.

*A transfer button? To transfer all the files so you could control the start of the renders better?

*A quick transfer button to refresh only the files that need to be (ie those with different versions)

*Some sort of monitoring panel (CPU, memory etc of all the nodes)

*Individual node displays to look for differences?

I know my ideas are reasonably big.... and annoying XD.
But I hope my ideas come in useful...

Edit: Ooops. I also put these posts in the request forum, i forgot there was one.... *slaps self*

[zuegs]

Hi Nick,

when i was playing with SSS lately i found that they look different with/without Bi-Dir.
Right box (2*2*2m) of following scene is a SSS with low uniform value 0.1 (ior=1.0)
The first image is without Bi-Dir and it looks corect for me (it's just a fine fog). The second image is with Bi-Dir enabled and there's a strong shadow:

[danyolgiax]

Hi Nick,

when i was playing with SSS lately i found that they look different with/without Bi-Dir.
Right box (2*2*2m) of following scene is a SSS with low uniform value 0.1 (ior=1.0)

can u post the fog material's XML?

[ludoman]

hi everyone,

i am using indigo7test7 with importing mesh in wavefront object file format. The object file contains the vertex point, the face connection and the accroding material, for instance:
usemtl ad0000FF
f 1 2 3
f 4 2 1
f 5 2 4
f 6 2 5
usemtl ad0808FF
f 7 2 6
f 3 2 7
f 8 9 3
f 7 8 3
f 10 8 7
thus in indigo scene i wrote:
<mesh>
<name>icm</name>
<normal_smoothing>true</normal_smoothing>
<external>
<path>new.obj</path>
</external>
</mesh>
<material>
<name>ad0000FF</name>
<diffuse>
<colour>0.0 0.0 1.0</colour>
</diffuse>
</material>
<material>
<name>ad0808FF</name>
<diffuse>
<colour>0.0313725490196 0.0313725490196 1.0</colour>
</diffuse>
</material>
<material>
<name>ad1414FF</name>
<diffuse>
<colour>0.078431372549 0.078431372549 1.0</colour>
</diffuse>
</material>
<model>
<pos>0 0 0</pos>
<scale>1</scale>
<mesh_name>icm</mesh_name>
</model>

As you see it is not a complex scene, but my problem is that indigo doesn't respect the material oreder attribution of face. Is it normal?
i attached two pictures, the left is the indigo rendered image and the left the correct color schems.
Is anyone could help me, or know why it is like this?
thanks a lot in advance!

ludo

[Kram1032]

please post your materials...
is it ONE mesh?
It looks like multible blends + Alphamap, to me...
but for now, indigo just supports one alphamap.
That may be your problem..