I was wondering if you could share a roadmap to a next release.
Is it going to be a maintainance update or a 1.x version?
Any time frame decided upon yet for that next release?
I was also wondering what will change to the workflow in a possible next release:
‘autolinking’ of all present SU materials + a ‘update link’ button for re-textured SU materials,some GUI simplifications etc…?
All just out of curiousity.
I hope you guys don’t mind.
I am still convinced you have a very powerful product to offer…It would be a blast if some workflow improvements and bug fixes would be done and wrapped in a new update release.
We are working on a service release at the moment that we are aiming on releasing toward the end of September to early October. I’ve broken down our Sketchup issues into a few general sections and I will list them in order of priority. I am interested in hearing response from you guys to see if you agree with my basic concerns…
Linked Materials
We are making linked materials editable - there are too many hacked workarounds required to do certain things with linked materials right now and it is all because of the read-only nature of the diffuse layer. So we’ve removed the read-only nature of linked materials so you can now edit them inside our material editor as well as the Sketchup material editor
We will be making it so we will automatically link all Sketchup materials in a scene when you open a scene for the first time. This seems to be a common step in migrating a Sketchup scene to a V-Ray workflow and it is easy to automate this process. (Just for you biebel )
We will be looking into any other bug reports relating to the linked mats and do whatever is necessary there to fix them
UV Issues
A great deal of our problems are traceable back to UV issues. Since UV information is only generated when a Sketchup texture is applied to a face many users are running into confusing workflows with poor results ( this is especially visible when users attempt bump-mapping and displacement mapping ). Some of these issues also are a combination of UV problems in unison with the Linked material restrictions.
We still haven’t figured out exactly what our plan of attack will be for the UV issues - so I’m open to any suggestions you all may have. Please keep in mind that this is just a service release - so we won’t be able to implement anything to extensive.
Nested Geometry and Lights
We will be tracking down the bugs that cause materials and lights and geometry to not show up properly when applied to nested nodes. Several users have sent me scenes to dig through so we should be able to track this down.
Nice info! About “UV Issues” i could say:
you could create “template” to see how it works… or even make materials related to a default size (like in 3d max, you can either select universal input or metric input (or even like skp, that makes it so simple).
Or even let skp be the reference of the uv… they have done a lot… seems nice keeping it simply.)))
Thinks you should add if time you have:
-the moon light (sorry, fryrender already have it, but, still nice)
-region render
-tabbed vray fb window
-ies lights… could it be done?? there is a free program to edit it:
IES Generator http://www.tom-schuelke.com/ies-gen3.exe http://www.tom-schuelke.com/pies.exe
-the ability to use photomatch to make a baked model!!! that is fun, already proved but to much work and few precision… could be better!
-section render (powerful!!!)
-light portal to optimize lighting calculation (nice feature!)
-proxies to make millions!!!
-64 bits (for future skp 7… maybe)
-mac version and LINUX server (so cheap and old machines could really help here!)
Thank you Joe for that update on the development of VfSU.
I think the list you gave is very complete and seems to hit the nails on the head. ;D
The most useful improvement in terms of fast workflow will definitely be the ability to ‘full edit’ linked materials. That will be great.
Also the autolinking of materials at start up will be a great benefit.
Will it be possible to also perform a ‘update the link’ command? This would make it possible to retrieve uv-settings if the user decides to re-map a texture in Sketchup.
A little example:
In an interior scene I model a painting on a wall. The bitmap is ‘positioned exactly’ on the painting in SU. When opening the model file this painting material will be autolinked. I edit the ‘vraylinked’ material (bump, gloss, etc…). Later on I want to change the bitmap of the painting. I load up a different image in the SU material editor and position it ‘exactly’, click on the ‘update link’ button of the Vraylinked material and it will automatically transfer the new texture to the diffuse slot of the Vraylinked mat…while preserving all the previous editing (bump, gloss,etc..) that has been done before…
The only thing left that I find hasardous to master in Vray is setting up transparent materials (glass, water, etc…) with maps assigned (bump, displacement,gloss map, etc..). Clearly starting from a linked material to set those up will be great but as I understand, sometimes those materials need to be ‘Vray2sidedMTL’ or ‘VraySK2SidedMTl’.
Maybe a simplification (automation?)for this could also be a major improvement.
Again Joe, thanks for the info…Vray for Sketchup is getting better and better and I already liked it a lot!
All of those are good ideas - for the service release we are primarily focused on workflow problems and bugs, no so much on adding new features. But some of those suggestions you mention are on the radar for future major releases.
As we’ve been working through some linked material issues I also have noticed some issues with UV information being incorrectly retrieved. A linked material should never need to be updated. It is supposed to be linked to the Sketchup material and gets updated prior to rendering and prior to editing to ensure it has all the correct, and current, settings. But, like I said, we also have seen incorrect results. So we are tracking that down.
The only thing left that I find hasardous to master in Vray is setting up transparent materials (glass, water, etc…) with maps assigned (bump, displacement,gloss map, etc..).
Clearly starting from a linked material to set those up will be great but as I understand, sometimes those materials need to be ‘Vray2sidedMTL’ or ‘VraySK2SidedMTl’.
Maybe a simplification (automation?)for this could also be a major improvement.
I think some of this should get easier with less restrictive linked materials and easier UV manipulation. I’m hoping that increased UV dexterity should alleviate the need to rely so heavily on linked materials - so cases where you need to use other material types will become less hairy to deal with. If it weren’t for our weakness in the UV-department I don’t think the linked materials would be as important as they are right now.
I guess the trick, as it always has been, will be figuring out the best way to implement some of these workflow changes.
I think your roadmap looks really good! all the major needs are considered. beside the displacement and sun/sky issue (which then hopefully automatically detects the sun position on each tab) I am really looking forward to have a stable working possibility to render more than one picture over night by using the animation feature of SU. That would be a great time saver.
thx for sharing us this information!
since you are focusing on workflow, may you also consider about the saving materials issue. this is beneficial if you are working on different computer and fle sharing. at the moment su doesnot treat the vray map just like su map. su save within the file those materials you use in the file, but the vray materials no. i think vray creates a link ( correct me if im wrong)to those materials that were imported. therefore when you open the same file in another computer, the files ar missing. so we need to copy seperately the maps that we use in the file and save it together, instead of saving them at the same time on one file. and its really affecting the workflow in sharing files.
is there any way to set up the number of cores used in a net work for each of the computers we can put in network… or make it 50% in every one of them so we can still work in those “slaves” (like low priority?)
We have added a “pack material” function to our material editor that will find all the bitmaps used by a material and put them all in a location chosen by the user. That won’t pack it into the skp file - but it is a start I suppose.
But maybe we can expand upon that functionality to actually embed the dependent bitmaps as sketchup textures so they get embedded.
Well you could choose “Low thread priorty” in our Global settings but that would affect every machine used in the render, not specifically targetted machines. So no - I guess there isn’t a way to do this right now aside from manually lowering the spawners priorty from within the window’s task manager on the individual machine.
Perhaps we could add a command-line argument for the DRSpawner to specify information like that.
I HAVE A QUESTION ABOUT THE UPGRADED VERSION. WOULD IT BE POSSIBLE TO RENDER OR ANIMATE CUT SECTIONS IN VRAY? I ASSUMING IT WONT FOR THIS COMING UP VERSION, BUT MAYBE DOWN THE ROAD? THAT WILL BE A BIG CHALLENGE FOR YOU GUYS AS PROGRAMMERS, RIGHT?
Probably not in the update because its meant as more of a fix as opposed to new features. Rendering section cuts are something that has been requested allot, so its something we’ve been looking into. The issue comes for the section not actually changing the physical geometry, only how it appears in the viewport. So when we grab all the geometry for the render the section cuts don’t matter because the geometry is still there. Hope that explains the “why its not working” a little better.
Is it possible to see the following view issue fixed? It would be really beneficial to be able to set the views according to what we see when we are modeling in sketchup. this would help streamline work significantly.
)