So I if I open one of our Render Peoples models directly from our network server, the material paths are fine
If I drop the model in using the component tray, the models lose there material due to the path being altered
So I am not sure if this is a Sketchup issue, VRay or Render people
or all of the above
someone please help, as I am losing my mind
When we upgraded to 3.6, the same thing happened to our component library of sketchup anima people that we had as vrmesh’s. I poked around a bit, but in the end, ended up just recreating all of them all as vrscene people via 3ds Max and vray. When I went back and opened the downloaded SKP files from anima, it says they were created in vray2, so I’m wondering what has changed since 3.4 because they worked correctly then.
Apologies for the late reply!
There is an active ticket about this issue.
@delineator , I assume your vrmesh components library was on a mapped drive as well?
Yes, everything (vrmesh and materials) are on mapped drives. In the end, I ended up recreating a chunk of our library as vrscenes as they seem a bit more stable (?) for now. I like how its just a universal vray model locked in time, and it works whether I import into Max or SKP. The same can’t really be said about the vrmesh’s because the multi-mats from 3ds Max tend to get jumbled coming into SKP and I have to recreate the materials from scratch. However, getting vrscene standalone models out of 3ds Max is a 2-click process and seems to be working for us right now
Thank you for your confirmation!
We’re hoping to have a fix for this in the upcoming v.3.60.02.
Kind regards,
Peter
Could you please share a sample SketchUp scene (use “Pack Project”) containing a component which exhibits the described issue?
Kind regards,
Peter
I should note, the above were taken directly from anima’s SKP downloads, converted into vrmeshes, saved as SKP components. Thats the only way we could get the materials working correctly in the past.
I went back and opened a SKP direct from anima (no vrmesh conversion), and it seems like the gamma conversion is off, causing these issues. Packed below, still didn’t include materials, which again, makes me think its defaulting to the SKP cache:
Dont’ know how helpful this all will be because these were made in vray2 initially, but let me know if you need other examples
Are you able to reproduce the same faulty results with components made in v3.6?
I think there is some confusion - the original file is the one that is now borked in 3.6. These were made by anima in vray2 and worked up thru vray 3.4. However, 3.6 broke both the original skp meshes AND the vrmesh proxies that we made.
As a test, I opened the original SU file, updated the pathing (which seemed to correct the material issues). The exported a vrmesh and saved that SKP file with the vrmesh component (for those that remember, this is the process we had to use back in vray2 to get vrmeshes to come in properly without rescrambling their materials)
Results: Straight vrmesh import scrambled materials and is useless. However, importing the SKP file as a component (the original file in which the vrmesh was made from), the materials seem to work OK.
Not sure what the conclusion should be, nor am I entirely sure what the issue really is. I can send file if need be, I can also clarify the steps I took if need be.
The issues with AXYZ and RenderPeople assets are, although related, different from one another.
Both use outdated v2.0 materials, which do not function properly after running through the automatic material migration scripts. Our developers are working on them and we are still investigating the issue with .vrmesh proxies. Based on your comment, I assume there is no problem with proxy components done in v3.60.01?
Kind regards,
Peter
Actually yes, but its the general problem of vrmesh’s rescrambling matID’s, even when saved as SKP components. Thats why with a few exceptions (laubwerk trees, etc), vrmesh proxies are persona non grata in the studio and we’re using vrscenes for almost everything. There are some downsides and I’m sure this will evolve over time, but right now I prefer the static nature of the vrscene file and its proven a bit more reliable when it comes to making and using proxies in our models.
