Chaosgroup plugin developement?

[Micha_cg]

Hi,

I ask here, because I hope, here is a better chance to get in contact than at the end of the forum.

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.

Regards,
Micha

[vlado]

If there is a way to port the old 1.05 to 64bit without getting a lot of bugs

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

[Micha_cg]

"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/vbu...9932-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?

[vlado]

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

[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

[Micha_cg]

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.

[v-cube]

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

www.v-cube.de

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 ?

[vlado]

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

Best regards,
Vlado

[plastic_]

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

[Micha_cg]

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 ).

[Micha_cg]

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/vbu...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/vbu...9932-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?

[vlado]

For me it looks like one developer is working part time on VfR

This is correct, yes. Joe's time is currently split between V-Ray for Rhino and V-Ray for SketchUp.

Since one month people post here that a DLL is out of date - no answer from the chaosgroup.

Even though there is no reply on the forum, the problem has been noted by our support guys and Joe already fixed a couple of things in the installer and we will update it on our website. I know that our support guys have handled many such cases and if you contact them directly to support@chaosgroup.com they will be happy to help.

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.

I described what the problem is, how to reduce the effect, and why there is no quick fix for this yet.

When can be expected a change?

Whenever we get more developers for V-Ray for Rhino, which I hope will happen soon - the hiring process has already been going on for some time and we found a few people that might be suitable.

Best regards,
Vlado

[Micha_cg]

I described what the problem is, how to reduce the effect, and why there is no quick fix for this yet.

Your described way doesn't reduce the effect. Only I open a file from R4 1.05, don't touch it and save it with R5 1.5 and the size is doubled, no chance to avoid it. Only a dirty workaround helps - setup the scene at 1.05 and load the scene as block (referenced file) to 1.5, where the new options/features can be used. So, there exist two version of the scene, a save 1.05 and a critical 1.5.
http://www.chaosgroup.com/forums/vbu...5&goto=newpost

I'm very curious when we will be at a pro level. One month past away since the thread is started, but the situation isn't better. I have seen now that the development focus seems to be lost to SketchUp, since a new SU version is released the last days. The parallel development is a pain for the user. I hope this can be stoped once a day and each 3D software get an own optimized code. The "one for two development" cause a development slow down and less features at both. At the moment the way is: SDK -> universal plugin -> SU or Rhino. If the universal plugin code would come from the Vray core team, than it would help at the plugin developing end with the little team.

[vlado]

One month past away since the thread is started, but the situation isn't better.

It will take a little more time to fix it; sorry about that.

The "one for two development" cause a development slow down and less features at both.

We know that, of course. It's why we are looking for more people. Unfortunately, good developers don't turn up the next day you put up a job ad (at least, Rhino developers; there's lots of people if you want to do websites ).

If the universal plugin code would come from the Vray core team, than it would help at the plugin developing end with the little team.

We have thought about that, too. But the US guys know their code best; trying to move that development in Bulgaria would not be very successful in my opinion.

Our biggest mistake here is that we didn't start looking for new developers right away - if we had more people months ago, the situation today would have been different.

Best regards,
Vlado

[Micha_cg]

"We have thought about that, too. But the US guys know their code best; trying to move that development in Bulgaria would not be very successful in my opinion."

A little bit offtopic - the last years I wonder how much render code must be developed by the plugin developer. Before Vray I used the renderman standard based renderer AIR (no competitor for Vray ) and there I have seen, how easy it was to add functions to the Rhino plugin. For example the plugin developer need to add simple lines like this to the render file.

Displacement "null"
Color [ 1 1 1 ]
Opacity [ 1 1 1 ]
Attribute "visibility" "integer camera" [0]
Attribute "visibility" "integer trace" [0]
Attribute "visibility" "integer transmission" [0]
Sides 1

Maybe the Vray SDK could be easier to use, so that the plugin developer are working on UI stuff most only, and not on render code. I wonder how long the plugin developer need to add a little function like "invisible for camera", if it could be a little line only.
The renderman standard allowed to add functions to the scene description file with a little bit knowledge only. It was funny times to work a little bit on shaders and options without to be a programmer. Every new function of the core code got a simple command and the function was quick added to the plugins.