Long Vray scene creation time

[david.anastacio]

Hi,

Any ideia why the vray scenes creation time jumps from 30 seconds on a 100 frame sequence, to an hour if I have an animated object inside it? That animated object being an alembic with its animation loaded through an alembic xform node (no deformations, just transforms). It's not writting a lot more data just a couple MB difference with that animated object in there or not. But it suddenly takes over 3 minutes per frame creating the vray-scene.
Any ideia?

Sharing an example scene on this will be hard, but I'll see if I can put something together from scratch since I can't send the production scenes.

Best,
David.

[bdancer]

> Sharing an example scene on this will be hard

Well, if you could reproduce this on a simpler scene, this will help.

[david.anastacio]

I'm having a hard time replicating the issue.
But in our production asset (it's an HDA) there is a huge difference from using the asset name in the force/candidate objects or targeting just the contents of that asset.

Using the name of the asset (HDA) makes the vrayscene take 40 second per frame:


Using "/*" after the name makes the vrayscene take 1 second per frame:


Or even faster if I target only the renderable geometries inside the asset, less then half a second per frame:


I'm going to try to find some time to see if I can dig more into this issue and to try and isolate the problem.
Any ideas why this is happening, or if someone else is having this is please shout. Thanks.

Best,
David.

[bdancer]

I have no idea from the screenshots, I need a scene...

[david.anastacio]

I have no idea from the screenshots, I need a scene...

Tottaly, makes no sense I know.
I will have to request permission to send a production scene first.

Best,
David.

[LeoYfver]

I actually just realised this 2 days ago. the hda took 2.5 min and just the content took 1.5 min. Not a scene i can share either though. Ill do a simpel one if i find the time

[Gosho.Genchev]

We're trying to reproduce this here - any pointers you may have will be of huge help, e.g.

1) Are there multiple sub-network levels inside
2) Are you driving the visibility of certain nodes with parameters on the HDA
3) Are there Instancer nodes inside, or some sort of instancing using Copy to Points or a similar method ?
4) Maybe a a screenshot of the network inside the HDA, if possible

Any info you could spare would help a lot!

Thank you!

[LeoYfver]

in my case:

1) yes in the hda there are subnets with other hdas or geometries
2)no, but controlling the frame range from an attribute on the hda in all the filepaths like this /path/to/object'ch("../../framerange")'.abc
3)pure alembics being split up in different geo nodes and applied shader and object properties on
4)will check

[david.anastacio]

Gosho.Genchev, thanks for taking the time to look into this.

1) Are there multiple sub-network levels inside
Yes and No. My current problematic asset does have HDAs inside of it, but I remeber of another huge spaceship asset that didn't.
2) Are you driving the visibility of certain nodes with parameters on the HDA
Yes and No, we usually have switches on the HDA level no enable/disable certain parts of the asset when needed. But in my asset yesterday those switches were not even linked.
3) Are there Instancer nodes inside, or some sort of instancing using Copy to Points or a similar method ?
Yes and No. In the one from yesterday no instancing going on. But that same huge spaceship I mentioned had "Instancer" nodes in it.
4) Maybe a a screenshot of the network inside the HDA, if possible
Yes. See attached images.

Additional info. This issue only seems show up as soon as you have animation in your HDA, the same HDA with no animation is fine. We are using alembic xForm nodes to drive the animation. And even if that xForm node has no animation (empty file path) the issue starts.
Yesterday I was trying to reproduce the issue in a simple scene, HDA, xform nodes, alembic geo, and I wasn't able too.
I'm trying to sort the authorization to send you guys the HDA that is causing issues, it looks like I'll be able too.

Best,
David.

[david.anastacio]

Gosho.Genchev and bdancer , I mailed you a test scene that has the issue described before. Let me know if this is enough for you guys.

Best,
David.

[david.anastacio]

Hi again Gosho.Genchev and bdancer ,

Update from my side, looks like using "hdaName/*" is also not a good idea. The only thing that seems safe is to fetch the geo inside of the HDA. When using the "/*" to get everything in it I had 2 issues, the first using the hda as phantom with the "hdaName/*" caused components of another hda to go crazy, flipping differently from frame to frame, this only happened on the farm (VFH standalone), locally it was working. The second issue was using the "hdaName/*" in the force objects made the reflection on that hda from a second hda that was set to phantom object to have black artefacts and missing reflections, that same setup rendered correctly locally but on the farm (VFH standalone) caused this artefacts.

Here's an example of that second issue:


On the left the farm render were the car was pulled using "carName/*", and on the right the local render result of the same exact setup. The environment is kind of missing on the side of the car, and the HDRI Dome is blocked by some black thing.
Just want to point out, everything in the hda is setup that only the asset geo is rendering/visible, that can be seen by the correct render result locally. Changing to only fetching the geo I want to render inside the hda then gives me the correct result on the farm.

This is quite a big issue when you get a different result locally than on the standalone, having to re-render 2 dozen shots right now because of this

Best,
David.

[Gosho.Genchev]

Hey David,

I'm really sorry to hear that this is causing so much headache for you. We're looking into this as top priority. I am still not sure what is going on but at least the issue is reproducible on my end as well. The problems you describe above seem related to the original issue with the export - if I had to take a guess, things that shouldn't be exported are, and vice-versa.
I'll ping you as soon as I know more.

Thank you!

[david.anastacio]

Gosho.Genchev that is good news, you being able to reproduce the issue is a major step in finding its solution, and I have no doubts that you'll be able to fix it
Yes, we are having issues, but what production doesn't. But like i said, the farm rendering differently from the local render is kinda of the worst ones, as you are confident the setup is ok and fire it off to the farm just to find out in the morning something went wrong.

if I had to take a guess, things that shouldn't be exported are, and vice-versa.

My money would be on that too, that would explain why animated xforms render locally and translate fast, and when the vrayscene gets created it lags. And also this black artefacts in the farm render. We setup everything with nulls inside when we didn't want something to render, or used vray properties to make it not renderable.

Thanks for keeping me posted.
David.

[GoodbyeKansas]

Is there any need for more scenes? We are having the same problem and could try sending something over as well.

-- Erik

[Gosho.Genchev]

Hey david.anastacio ,

we've sped up the export in the latest nightly build but I have some concerns that this won't fix the reflection issue from your previous post.
We know what's causing this now but fixing the root cause will take a bit of time.

Could you please give it a shot on your end, e.g. like this:

Force Objects: car_master1/* ^car_master1/driver ^car_master1/ABCCACHE

GoodbyeKansas , that would be very much appreciated - as always, if you hit an issue, please don't hesitate to ping us and mail us anything that could help.

Best regards!