Hi,
I’m not having time to go deeper into the topic here, but after installing the new update, all my existing proxy libraries totally got mixed up. Some proxies were displaced, other totally blown up. Please open an existing proxy file, containing multiple proxies and have a look on your own. I can post more detailed screenshots tomorrow if still needed.
btw I was close to tears when reading this:
Superhappy!
Hi @toniboni
I’ve made a simple test of creating proxies in a version prior update 1.1 and can’t seem to notice any issues when opening the files with update 1.1. Would it be possible to share more details regarding when were those proxies created, maybe share a file with such so we can test with different versions and see if we can reproduce it here? Thanks!
Sure. Thanks for the quick reply, Nikoleta.
So, the problem remains. Please find attached my template file screenshots. The people proxies were scaled exactly by 1000 (see size of groundplane). So is the tree. I’m attaching the file to this post here as well. People proxies were created about 2 weeks ago with the uptodate version back then. Tree proxy is way older, probably something like a year or two.
Weird fact: It is my template file. So if I open Rhino, the file automatically loads. If this happens, the proxies are normally scaled. Everything fine. But only if I open the file regularly by double clicking on it in the windows explorer, the described problem occurs. Strange, isn’t it?
So I have this problem appearing in my proxy tree library as well, but here it seems like also some positioning issues appear. Seems like they have been moving around and got scaled as well. Something with the base point? Let me know it you need those files as well. They are big, so I don’t want to spam here.
It think this should be treated with high priority. Thanks
Toni
File download here:
https://owncloud-sonaar-at.prossl.de/s/lQ2333Tm4xEljUY/download
Ok meanwhile I have found out the following: If I try to fix this manually and the scale the proxy in Rhino back to its original size (by factor 0.001), the proxy apperas in right scale in Rhino BUT not in the rendering. Only when I rescale the proxy in the vray proxy scale settings to 1000, Rhino viewport and rendering correlate. Quite a thing, please have a look at this asap. Thanks
Hi @toniboni - the latest link requires a password to download them. Would it be possible to forward them via our contact form? Also, can you let me know if you’ve upgraded Rhino versions as well?
Oh sorry, sure. Rhino version is newest.
Packed file size is larger than 100mb. Password is template.
Thanks, @toniboni
I am able to reproduce this with your files in our environment as well. Will need to explore further as to why is it happening, I’ll keep you posted. The odd thing is that, at least on our end, they appear blown-up but are rendering as expected.
Moreover, random objects are scaling like that upon closing and re-opening the file (i.e., sometimes the tree would blow-up, other times - it won’t). If I change the proxy Preview Type to Whole Mesh, they will go back to their expected scale;
if I set them back to the original Proxy Preview, they will remain the way they should. So I guess you can use that as a workaround while we investigate.
Can you additionally let me know where are those proxies taken from? Thanks.
Hi NIkoleta,
Ok, thanks for letting me know. So, I have created the proxies on my own, trees coming from evermotion and the people coming from archihacks. I hope you guys are able to fix this asap. Thanks, Toni
Btw I have encountered the same behaviour that you are describing. Concerning the difference between viewport and rendered scale as well as the random appearance of this bug.
@nikoleta.garkova no fix for this issue in the new update?
Hi @toniboni
Apologies for the delay.
I am afraid that since we cannot reproduce this issue by creating a file with proxies in an older version and reopening it with the latest one, we are unable to devise a proper solution this particular situation.
It’s most likely that the scale factor is not serialized properly, but as we cannot be exactly aware how were those template 3dm files created and whether there is any other plugin data while making the proxies, our only advise would be to re-do them with the latest version of V-Ray 5.
But you were able to reproduce this behaviour! As stated above! I can’t believe that I have spend money on buying your product, installing every single update, relying on it, building large proxy libraries (which has been very annoying with vray back then), spending days after days working on that and now you tell me this?! Just redo them? Well, not really nice, don’t you think? Not really the service I have been expecting.
As already mentioned, the last proxy was created 2 weeks before installing the update. It’s not that I am using vray 2.0. It’s been the top notch latest version. You should care about these things.
Big disappointment.
Moreover I have spend some time in the bug documentation process to allow you to create a better product. This sucks.
Hi @toniboni
We are able to reproduce it with the specific 3dm file you sent us (I’m not saying otherwise), however, we cannot get the same behavior if we try to make a proxy template file from scratch.
We can, of course, schedule a remote session and investigate a bit further the creation process of those files and troubleshoot on the spot - if that is alright with you, you can get in touch via our contact form to do so.
Ok, we can do this, but for me it is not so much about the creation process anymore, since I’m using the newest update of Vray 5 now and I suppose that the bug will not appear here. But remote session sounds ok…I’ll use the contact form.
Hi toniboni,
We have identified the cause for this issue and it’ll be resolved in the next update.
The issue is logged in our internal bug tracking system as VRW-3189.
Thank you for reporting this and excuse us for the inconvenience.
Regrads,
Konstantin
Hey that’s good news! Thanks for letting me know… Excuse accepted 
Now I hope for the update to appear asap.
Best regards
Toni
