Hi, I ask here, because I hope, here is a better chance to get in contact than at the end of the forum. :wink: I’m a Vray for Rhino (VfR) user and use the five year old VfR 1.05 plugin everyday several hours. My clients are happy and I have a lot of work, but over the time the project size increase, from small design projects to whole train/air plane interiors. So, often I run in the limitations of the 32bit environment, it’s not easy to get heavy scenes done. The new 1.5 was strong anticipated - five years for a new release are a very long time. After five years, this spring a new version of VfR (1.5) is released, but it doesn’t match the quality of a final software, it can’t be used without the risk to collapse within a project - it’s the worst case for a freelance. The new plugin is a big step behind the old version (32bit only), the old one was rock solid and the UI quite well arranged. Since the 1.5 is official released (before the bug list of the beta was cleaned) I hoped to get quick bug fixes for critical bugs within a few hours or days, so that projects can be finalized. But it looks like weeks or months are needed. So, please, dear chaosgroup teams, please try to find a way to get more power to the plugin development. Please find a way, that the development is focused to VfR, so that the progress is visible within days and not within months. From my users view it looks like the development lost the focus again and again, only a few bugs are fixed every few weeks. If there is a way to port the old 1.05 to 64bit without getting a lot of bugs, than I could wait some years more for a new plugin version. Sorry for the hard words, but I’m very nervous, because a big project starts soon and as I scheduled the project in the summer time, I thought, the critical bugs are fixed until autumn and I can work at 64bit. Since chaosgroup acquired ASGvis I hoped this deal is showing a positive effect for VfR users too, but for me as pro user … I can’t sleep well if I think on to use VfR 1.5 for my next project. :frowning: Regards, Micha

I will ask, but I don’t know how much work it is to recompile the original code. Other than that, I know that the guys work hard to fix bugs, but there is just not enough time to look at everything. That’s why we’ve been looking for more programmers to help with the development in the past few months. Best regards, Vlado

“Look at everything” wouldn’t be needed, but there are a few very critical bugs that makes, that projects can’t be done. Please look at the changelog of the nightly builds - doe’s it look like critical bugs are fixed within an usable time frame? Two current critical bug example: proxie usage cause that the scene is randomized (case 8093, reported two weeks before or longer by other users) and using the 1.5 plugin cause, that the file size increase a lot: http://www.chaosgroup.com/forums/vbulletin/showthread.php?69932-File-Size (no reply by the team) I started to test VfR 1.05 beta in 2006/2007 and there bugs was fixed very fast. I was in contact with Joe at daily base and project critical bugs was fixed, so that the projects can be finished. Is it not recommended to use 1.5 for commercial projects now?

Will check what’s the status of these and hopefully they are simple enough to be resolved quickly. In any case like I said, Joe is overloaded right now - which is why we need more people in order to be able to address issues faster. Best regards, Vlado

So from what I understand, Joe has found the problem with the proxies and is currently working on fixing the issue. For the scene size, I’ll just quote him:> As for issue 2, I have not yet come up with the best way to approach it. Part of the problem is that Rhino is odd about how it makes and stores materials. You can have 1000 of copies of the same material depending on how you apply your materials. This is why I generally tell users to use our material editor to apply materials where possible, as we ensure we only apply 1 material to all objects selected, whereas Rhino, in some cases, will assign a separate copy to each item in the selection. Since we are now using XML, and also embed a preview image in that xml, our materials are much larger than their old binary counterparts. So for now I tell users to try using our material editor for applications as much as possible. In the future I will probably have to revert to storing binary information, which is part of why I started experimenting with serializing to binary in our asset table a week or so ago. Just going to binary won’t be enough, however, since the embedded preview adds 25-30KB anyway. Switching to binary can give us about 30% reduction, switching to binary without the image can take us further. I have not been actively working on this, though it has been in the back of my mind. Unfortunately, the best way to eliminate size would just be to make the materials hold a url and reference a separate table. However, this would greatly complicate things when users choose to copy and paste between scenes ( which they seem to do according to old bug reports ). If our material isn’t on the ON_Material when its copied, it wont’ be brought to the new scene. So there isn’t a fool-proof fix that will make everyone happy yet, but I will continue looking into it. Let me know if there is anything else. Best regards, Vlado

Thank you Vlado. Please try to find ways that VfR doesn’t stay a problem child, Rhino is a great tool and Vray could be the best renderer for it.

Well I can really understand Micha, I am nearly in the same position here. I am a vray user from the start, at first with 3ds and later with Rhino. For me it was an unbelivable relief to get rid of all that overhead ( exporting meshes from Rhino, importing into 3ds, (re)assigning materials and mapping coordinates…) so I gladly traded the advanced possibilities of the 3ds version for the leaner workflow of rendering stuff within rhino. Rhino 4 in concert with vray 1.05 is still my workhorse for nearly 95% of all Projects, and apart from the known bugs and shortcomings of both software packages, it is a rock stable combination ! I was a bit shocked when vfr 1.5 was initially released, because despite of many cool new features, in combo with the R5 of that time it was unusable for (my) professional work, so I stayed with the old trusted combination. In the last months the situation has improved significantly, a number of critical bugs were ironed out and a few weeks ago I was able to finish my first professional project with the R5 vfr 1.5 combo ( I did that mainly to avoid 3d studio and be still able to use proxies) So I really wish the new combo will finally become a successor. Like Micha I still have some issues (e.g. not being able to assign a material from the rhino layer dialogue, proxy issues especially in conjunction with blocks, no HDRI multiplier? …) with the new combo which is probably partly due to both packages, even more because rhino 5 64bit is still in its (final?) beta stage. So My personal hope is that once rhino 5 released, we will have a “matching” vfr that has the bugs ironed out we are still seeing. best regards Andreas Walther V-CUBE – Professionelle Visualisierungen P.S. a little OT but is there a chance to see better animation support for vfr e.g. a working “incremental add” mode for the ir map or a LC for a camera path ?

Yes, as I mentioned before, everyone involved understands your concerns and we are working to improve the situation. Best regards, Vlado

I’m not a Rhino user (isn’t this the max forum?), but I’d like to add that given the situation with Autodesk and what’s happening with 3ds max development and given that I’m quite unhappy where max is heading (and I’m not alone), I’d like to see Vray for Rhino being as rock solid as Vray for 3ds max. Because, for archviz, Rhino is pretty much the only other option I see, so I greatly support the idea of a good Vray for Rhino :wink:

Yes, Rhino is a loved tool by many designer and architects. It allow to use NURBS data and to interchange models per STEP, so it’s great tool for interchange data between designer and engineers. VfR could be the best biased engine for Rhino, but it need much more development power. (I know it’s the max forum, but the Rhino forum is at the end of the Vray world :wink: ).

For me it looks like one developer is working part time on VfR - since 2 weeks only two little bug fixes. Vlado, please look at the changelog of the beta builds. Since one month people post here that a DLL is out of date - no answer from the chaosgroup. http://www.chaosgroup.com/forums/vbulletin/showthread.php?69963-Dependent-DLL-is-out-of-date Since one month there is a post, that the new 1.5 version blow up the file size, but there is no answer or solution yet. A project file increase from 350MB to 700MB. My impression is, that VfR 1.5 could cause strong problems. Will the project files be wasted by the new version? I reported the bug with a large example file and wrote, that I need a feedback, if the big example file downloaded from my server so that I can delete it. No answer since two weeks yet. http://www.chaosgroup.com/forums/vbulletin/showthread.php?69932-File-Size VfR 1.5 doesn’t match the quality of a professional tool and the support too. VfR isn’t a fun spare time tool, it’s used by professionals within tight deadlines to earn money to live. We need quality and support!!! What is going on? When can be expected a change?

Chaosgroup plugin developement?

V-Ray V-Ray for 3ds Max General

vlado October 18, 2012, 9:26am 16

They don’t work on render code directly. As you see, the large majority of issues are not related to rendering at all, but to the integration with Rhino, installations, UI bugs etc.

Best regards,
Vlado

Topic		Replies	Views
Is this product still being updated? General	75	7516	November 24, 2011
Vlado, please help: Rhino users need you General	22	1319	October 27, 2017
Vray... we need to talk Public	24	2134	November 24, 2017
Development update General	78	4228	May 16, 2013
Ok it´s 16. June today General	115	4794	June 24, 2004

Chaosgroup plugin developement?

Related topics