Is 3.6 Broken?

[iCreate]

Hi all.

I've been trying to figure out for ages the best method for rendering my animations in 3.6.

It seems that the way people render, or are expected to render has changed. Quite a few people seem to get as baffled as I am.....

I have always used the following method:

RENDERING LIGHT CACHE

I use the following method.

In Common, I have it set to Single Frame

I have 'Don't render final image' TICKED. I don't use distributed rendering.

For this stage I press render in the VFB. It creates a flythrough, ghostly image (cos of use camera path).

I then save the LC in the render settings box.



GI

For the GI I use the following:

I use distributed rendering for this stage.

I use the render button in the render setup box




This method meant that I have a full light cache for the animation.

I use the same light cache for all shots.

I can use distributed rendering for all shots (which I render separately).

PC's helping with the GI cache pick it up almost straight away.

I then save the irradiance map.

RENDER


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

However, this now doesn't work.

Use camera path seems to be broken.... It gives the same results whether on or off.

Flythrough only seems to render the last frame.

If I render the LC (even though it doesn't seem to be working correctly) and save the file.

When I try to render the GI, it can't..... It gets stuck on compiling geometry.

REALLY REALLY ANNOYING

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

So, I'm now having to use the following method:

Primary = IM
Secondary = LC

IM:
Multiframe incremental
Use camera path = UNTICKED

LC:
Mode = Single frame

The light cache info is saved into the IM file

================

When rendering:

Primary = IM
Secondary = NONE

==================

This is working but is taking ages to create the cache. Only I seem to be creating the light cache and other systems only contribute when I'm 3/4 into the frame.

It can take a few hours to create a cache.

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

Can anyone help with this?

Can I send my scene to Chaos?

It's too late for us to go back to 3.4 because we have a few jobs using 3.6.

I don't have time to get to grips with Brute Force & LC....... I'm on a deadline and trying to get an animation out.... it's turning into a nightmare.

Thanks

Sean

[svetlozar.draganov]

There was a bug in LC with Fly-through mode and Use Camera Path option which has been fixed in V-Ray Next.
Unfortunately the patch hasn't been ported to version 3.x.

Is there a chance to test if you got correct result with V-Ray Next?
If not would it be possible to send us the scene so we could check it for you?

Looking forward to hearing from you.

[anthonyh]

Hi,
is this likely to be fixed for 3.6 for those of us who can`t upgrade to Next just yet ?
thanks
anthonyh

[svetlozar.draganov]

It depends, usually porting something from 4.x to 3.x is not an easy task because of the different SDKs - many things could break and due to that we need to be very very careful.
If the bug is pretty important though and if there is no workaround we'll do our best to port it back.

[anthonyh]

To be fair, I just realised I don`t tend to `use camera path`, I tend to just use Incremental Add and Flythrough so if they still work I guess I`m ok. It`s always worked in the past, never needed camera path..
Only for cheapy exhibition stand flythroughs etc. Just doesn`t warrant the extra render time with brute force.

[iCreate]

Hi.

I've just sent an email.

I know nothing different than the steps in my post above.. Use camera path worked when I first rendered an animation so that's what has been used since then.

Thanks

[anthonyh]

Well it looks like whatever affects `use camera path` also affects the flythrough LC method I use as well, it doesn`t `smush`, it seems more smushy if you generate the LC with just single frame render although I doubt it`s working properly if Chaos know it`s a bug. Would appreciate a fix for this.

[samuel_bubat]

It depends, usually porting something from 4.x to 3.x is not an easy task because of the different SDKs - many things could break and due to that we need to be very very careful.
If the bug is pretty important though and if there is no workaround we'll do our best to port it back.

We' re pretty much in the same situation. We have a very old renderfarm wich consists of dozens of old quadcores. We' re planing to replace all of our machines in the future (more cores less machines). For now it wouldn' t make sense to pay thousends for rendernode upgrades. So we' re stuck for the moment with Vray3.6. How likely is it that this bug will be fixed in 3.6 ? Otherwise we would go back to 3.5.

[iCreate]

Right, caching in 3.6 is driving me nuts. Taking much longer.

I can't get Vray Next.

We have quite a few projects in 3.6 now. Can we downgrade (it'd actually be an upgrade as far as I'm concerned) to 3.5?

Can't believe Chaos screwed this up and won't fix it.

[matanov]

Sorry for the inconvenience guys . I'll see what we can do to port it to the 3.6 stable nightlies next week.

[iCreate]

Sorry for the inconvenience guys . I'll see what we can do to port it to the 3.6 stable nightlies next week.

If you can, that'd be amazing !

[anthonyh]

If you can, that'd be amazing !

Seconded. Really appreciate it.

[matanov]

You can try with tomorrow's 3.6 stable nighties

[DanSHP]

You can try with tomorrow's 3.6 stable nighties

Do the update 3.6 nightlies contain updates to fog and using IPR? Or is that just vray next nightlies?

[matanov]

Do the update 3.6 nightlies contain updates to fog and using IPR? Or is that just vray next nightlies?

If you are referring to the regular V-Ray CPU IPR - yes it's in the Next nightlies and will be included in the Update 1 for V-Ray Next.