Confusing scene size error behaviour

[fixeighted]

I have a 1.5gb scene with a load of Foest/Railclone in it.
When live linking, it gives gpu memory errors and will not load.
However, if I disable all the Forest and Railclone stuff, it loads - but then allows me to turn it all back on without issue.
This is surely not working as intended and it has driven me crazy all day trying to figure out what I am doing wrong.
Obviously I need to save a vrscene ultimately, so even if this weird live link thing works, it's not good for the workflow I need right now.
As usual, any advice is more than welcome.

[Phillip Miller]

Have you tried exporting the full scene to vrscene and loading it in Vantage? (while Max isn't running)
Let's verify first that Vantage can load your full scene in your GPU memory.
When live-linking, Vantage shares GPU resources with Max, so there could be some competition going on that is giving you the odd behavior you're seeing.

- Phil

[fixeighted]

Hmmm.... that doesn't seem to make sense to me, as with live link running it will load the scene with everything turned off, then I can can sinply turn everything back on and it updates, live, to the full scene.
If I try to save the full scene with everything on, then it will not load at all.
So, it can clearly load the whole scene one way, but refuses to the other way

[Phillip Miller]

OK - you didn't say before that a vrscene export wouldn't load.
So if a full export doesn't load in Vantage directly, but a live link session of the same scene will load, then it sounds like there's some efficiency being lost on export.
Any chance we can examine the scene? You can privately send us an uploaded link (dropbox, gdrive, etc.)

Kind regards,

- Phil

[fixeighted]

Ah yes, sorry, I did write that but then edited it for what I thought was clarity and forgot to add it back in
It was very late after a bottle of medicinal vino

Anyway today, even what was working yesterday now does not work.
I tried running the scene through gpu and if I turn all the Forest/RC off then it runs.
If I turn on any again, then the device fails, never to work again in that session, even with them all off and having restarted the device select.
I have brought the file size down from 1.3gb to 500mb and will send you a pm link to it.
Thanks for taking the time to look at it.....3 days trying has broken me

[npg]

Sorry for no reply from the tech team last week, but there were a bunch of holidays here.

So in your last post I think you're referring to V-Ray GPU also having issues with this. If that's the case you should probably start a separate thread in their forum section.

Now regarding Vantage, if I understand correctly if you enable things one by one it manages to load, but if everything was enabled before loading into Vantage it fails. This might be because of "peak memory usage" - there is some additional memory used while the geometric data is being crunched on the GPU before it starts rendering. When everything is loaded at once it stacks up.

Have you tried disabling the "safe GPU allocations" option in the Preferences dialog? Disabling it increases the chance the app would crash, but in some cases the system may manage to work even beyond the nominal GPU memory capacity (due to some Windows memory management voodoo going on).

[fixeighted]

What wasn't at all clear is that yes, many things seem ok using livelink but then the vrscene export would fail.
I've no idea how I was able to push it to use 17gb, as I only have a 2080ti.
I have given up thinking about that.

I do see the alert about 'safe GPU allocations' but had no idea what to do to even test that. The alert suggests that pressing 'yes' in that dialogue enables it, so that's a bit misleading and I thought it just wasn't working

I have the scene stripped to the bare minimum, as I am out of time to test this. It's a live project and for the time being it works enough to be able to
get the shots done, IF as is suggested in my separate post, https://forums.chaosgroup.com/forum/...ax#post1113213 you guys can possibly implement just the animation of focus changes
I am not sure what will happen if I can't use this....I suspect a meltdown

[npg]

The Yes/No question you refer to only changes the "safe allocations" option temporarily. The Preferences dialog controls the permanent setting. I see how it could be confusing.

[fixeighted]

Oh I see. I never got it to do anything, as only the 'no' option worked....pressing 'yes' did nothing.

[npg]

With Live Link? Seems like we overlooked this case. Pressing Yes reloads the vrscene file... which does not exist when running Live Link. So you'd have to toggle the option from Preferences to see if it makes a difference.

[fixeighted]

Ok, thanks, at least I know where the option resides.
What I 'was' doing is to use Livelink to test the scene as it was being populated with increasingly more Railclones/Forests,
so I could then judge what was feasible when actually exporting, in order for my actual cameraman do construct his shots.

However that clearly does not work, as the live link has essentially a different 'operating procedure', so what I see during live link
doesn't necessarily mean that is what I am going to get on export.
So that workflow is screwed unfortunately, and I now have to continually export the incremental updates to check they work.
Not ideal, but now I know the limitations of the live link I can avoid using it, for the most part.
It's a shame but it's still a good piece of software and has helped enormously so far

[vladimir.nedev]

However that clearly does not work, as the live link has essentially a different 'operating procedure', so what I see during live link
doesn't necessarily mean that is what I am going to get on export.
So that workflow is screwed unfortunately, and I now have to continually export the incremental updates to check they work.

The only differences between the live link and the vrscene should be the different way animation is supported and the potentially different handling of out of memory conditions.
Apart from these, the live link and vrscene go through exactly the same code and the results should match between the two.

Greetings,
Vladimir Nedev

[fixeighted]

Sure...I do believe you of course; and your explanation here does support this workflow, in this case anyway, being not workable, if there are 'potentially different handling of out of memory conditions'.

Anyway, having massively reduced the overall content and split the scene into definitely working chinks, I have it working in a condition that suffices, so I won't push it any more, as I've
established a 'known limit' for myself in a sense.