Jump to content

Very weird rendering omission in Vision


Recommended Posts

Here's a weird one that I just want to document before looking further or coming up with a workaround:

 

The Stage Right PA disappears... or has a partial "cloaking device"!

 

This is a screenshot in real time:

image.thumb.png.0bcc963b7b300f3888cb9ca7519b19b5.png

 

And here's a rendered still generated from this exact scene:

 

image.thumb.png.dbf20f25af14206aa598ba8188641112.png

 

What's happening here? I suspect maybe the PA symbols were mirrored when inserted in to the VWX model, so I'll start there. But right now there's a black hole that swallows these objects on rendering. Notice that the bottom cabinets on the SR PA are visible, and it's not all black; the fixtures on the truss behind are quite visible.

 

I suspect Romulan technology, stolen by the Klingons... but i'm not enough of a Trekkie to take that metaphor any further...

 

Any thoughts?

 

aj

 

 

Link to comment

Tried re-exporting the MVR in both "new" gITF format (the new default) and "legacy" .3DS format. Same results.

 

Tried opening a new VWX document and copying all of the PA from my document and pasting in to a fresh layer in a blank document, then export MVR...

 

This is what I saw upon copying:

image.png.1f1bf92c4d4ca9e0d20f097a889e3d1d.png

 

So perhaps my PA symbol, originally created with the Speaker Array tool, is compromised in some way. 

 

aj

 

 

Link to comment

OK here it is with just a big block (extrusion converted to Generic Solid) where the SR PA should be. This black hole is affecting that top corner of the rendering in every instance:

 

Realtime:

image.thumb.png.4f30d40a1fe8576686a14a38b3d5b607.png

 

Rendered Still:

 

image.thumb.png.d3a0db67bb0521ffb87802d308aec9d0.png

 

These images began as a blank VWX document and that big box SR is the simplest geometry, so there's no possibility of some weird "speaker array tool" problem or other thing due to records, etc. This is simple geometry that won't render.

 

It gets more interesting when lighting devices are added behind that big block. I tried just copying a few PA stacks behind that block in the model, and they still don't render. However, lighting device output will render through the black hole. The geometry of the fixtures themselves, however, don't render.

 

Again, this is realtime:

 

image.png.847a9e2ed13953f777479a4ba027f61c.png

 

And this is the render:

image.png.1325d5c2f098c541af2b0f79654f7e92.png

 

I'm out of quarters on this one... The same MVR files would render properly before the SP3 update, so i'll have to see if i can find an old installer and get back to work.

 

I have attached the VWX file from which I created this MVR and these renderings in case someone can break the code and figure this one out.

 

Thanks

peace

aj

 

 

 

 

 

Arena PA CornerRenderProblem.mvr Arena PA CornerRenderProblem.vwx

Link to comment

I can confirm that this does NOT happen in the previous version of Vision 621747

 

However, any MVR exported with the new gITF feature will not render that geometry in the old version (obviously), so all MVRs have to  be exported with the legacy .3DS option to show up in that version of Vision.

 

 

Link to comment
  • Vectorworks, Inc Employee

I'm trying to dig deeper into this issue. I happened to have an SP0 and SP3 build on my machine and so I've been testing with those. I can reproduce this issue in SP3 but not SP0; which is odd because as far as I'm aware none of this render still code changed with SP3. One thing that does seem to have an effect on this is resolution (viewport and/or still resolution). I thought it may be related to the "bucketing" feature of stills, but I'm no longer confident that is the case. I'm investigating and hope we can turn something up.

Link to comment

@bbudzon By "Bucketing" do you mean the process of rendering one "rectangle" at a time then stitching together like a panorama photo? 

 

In the original version of ESP Vision, when you asked for a still render this process happened right on the screen so that it appeared that it was panning across the scene...

 

This is what I was thinking (though I'd have no idea how to fix it)... that perhaps the first of these "snapshots" was missing some line of code that reappeared when the program cycled to the next one... and it only applied to non-light geometry since we could see the light beams from fixtures in that "frame"

 

All of my tests were with viewport resolution of 1280x720 rendering to a still at 3840x2160. Interesting that changing that gave you different results.

 

Link to comment
  • Vectorworks, Inc Employee
2 hours ago, ajpen said:

By "Bucketing" do you mean the process of rendering one "rectangle" at a time then stitching together like a panorama photo? 

 

In the original version of ESP Vision, when you asked for a still render this process happened right on the screen so that it appeared that it was panning across the scene...

Essentially, yes! You pretty much hit the nail on the head with "stitching together". I think another easy way to explain it (as there are so many VW users) is the little squares you get when rendering with Final Quality Renderworks. I'm not sure what the proper terminology is here, but I like to think of each "little square" as a bucket. Once all of the buckets are full, you can "stitch them together" to create your final image. We support this "bucketing feature" with rendered movies as well, although all of my testing so far has been focused on stills.

 

2 hours ago, ajpen said:

All of my tests were with viewport resolution of 1280x720 rendering to a still at 3840x2160. Interesting that changing that gave you different results.

One thing that is somewhat misunderstood is the viewport resolution. This is really more of a "capped resolution" rather than the resolution we render at. So, for example, if your viewport is only occupying 600x500 pixels on your monitor, then there is no need to render 1280x720 pixels (unless you want supersampling/multisampling); doing so would just waste performance. If, however, your viewport is occupying 2000x1500 pixels on your monitor, then we use the 1280x720 as a "cap" of sorts to avoid having a negative impact on performance by rendering the viewport at a higher resolution than was requested.

 

The reason I bring all of this up is because I am trying some odd things in my own tests:

- changing the viewport size on my monitor by resizing the windows/palettes; tall/skinny, short/fat, square, etc

- forcing the viewport size to match my monitor resolution by entering fullscreen

- changing the Resolution Quality setting in Vision's application preferences

- changing the image output resolution setting in Vision's render still dialog

- changing the image output settings to use various Render Buffers Sizes

 

The reason I believe this may not be tied to bucketing but rather resolution somehow (the truth is the two kind of go hand in hand) is that you can essentially "disable" bucketing by ensuring there is exactly one bucket. My monitor is 1920x1200. So, if I set my Resolution Quality to 1920x1200, enter fullscreen, render a still with "<Active Settings>" and an output resolution of 1920x1200, then only one "bucket" is needed. So, there is no "stitching" in this case. Yet, I still end up with broken stills. In fact, more geometry was missing in this case than in other tests where only the top left corner of the render was missing. It's like the first bucket always fails maybe but all subsequent ones succeed or something? This is odd because when stitching does not occur, this is the simplest case and generally speaking it should always succeed as it's basically just pasting the viewport into an image file on disk...

 

Just to reiterate, even when playing around with all of these settings/configurations, I cannot seem to get 2022 SP0 to "break". It always renders the still as I'd expect. So, I can confirm your report.

 

While I can sometimes get 2022 SP3 to "work", it is very finicky and difficult to reproduce. It seems more often than not, the rendered still is broken and I can't find a rhyme or reason as to what is causing it just yet.

 

We'll continue to investigate this and see what we can determine. Because it has been so finicky and it is hard to determine from testing what might be causing this, we might be best suited to look at every change to the code between SP2 and SP3 and try to find/fix the bug that way.

 

I'll try to provide an update here once we have something definitive to report.

Thanks for catching this issue and my apologies for the inconvenience!

Link to comment
  • 2 weeks later...

Hi @bbudzon

I have read through the thread here, and i might get the same issue as @ajpen

 

My renders makes a black square in the top right conor of the image. 

Do you think there is a relation? 

 

I made my model from a MVR export from Vectorworks. 

 

220411_7DS_MANUALEN_SAMLET-20220411171013.thumb.jpg.f9d5d79c88f2716726d18145fd4df44d.jpg

 

 

When i go MAX quality, and match my resolution to my monitor, i get this resault: 

220411_7DS_MANUALEN_SAMLET-20220411171905.thumb.jpg.201a48c35deee80cecd92d7093aa65b2.jpg

 

2116496785_Screenshot2022-04-11172108.png.b768a48e113c0e2f6ebcdbb51e73ea9d.png

 

Have you found out moere about the problem? 

 

Best from mathias 

 

 

Link to comment
  • Vectorworks, Inc Employee

Sorry all, I had an emergency and was out all of last week visiting family.

 

I do think I've narrowed down what change caused the issue, but it is still not clear why. I hope my continued investigations will turn something up.

 

I do have one suggestion though that seemed to work for me in my tests. If anyone experiencing this render still issue could try this workaround and report their results that would be great.

 

The possible workaround involves disabling PSN. To do this, open the Vision Application Preferences dialog, go to the Session tab, and uncheck the Enable PSN checkbox. Click OK on the dialog and you should be good to go. I did not need to restart Vision or reload the file to get the Render Still to work properly.

Link to comment
  • Vectorworks, Inc Employee

Thank you for your kindness 🙂 

 

And I'm glad disabling PSN worked! Now, if I can just figure out why 😛  Most of the PSN code has very little relation to realtime rendering code, let alone rendering stills. At least we've narrowed it down to a single change. So, there is much less code now to investigate.

 

I'll try to keep this thread updated as I discover more information.

Link to comment
  • 1 month later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...