Archived Old Bugs

[heatherchet]

Re: ****Please Post All V-Ray for Rhino 4.0 v1.0 SR1 Beta bugs here.****

Thanks for the ideas. I was able to folow the steps to uninstall the new RDK and re-install the old RDK. Everything is working again. I did try the suggestion of copying the DRSpawner files from the master to the slave and could run DR but did not have luck in rendering. Perhaps due to the license server which I did not change.

SR1 Beta comments:
1)In general when I was able to render (no DR) with the SR1 beta SW the few that I did came out super washed out and over exposed compared with VfR. Here is an example of the same model rendered with Vfr 1.0 and the second with VfR SR1 Beta. I assuming there is something up with my environment settings but I did not invstigate further.
2)Any 3dm files opened with the beta could no longer be opened when I switched back to VfR 1.0. Rhino would complain about invalid minor version number. Once I restored my 3dm files from before the upgrade I could open them again.

[dalomar_cg]

Re: ****Please Post All V-Ray for Rhino 4.0 v1.0 SR1 Beta bugs here.****

1) Not 100% sure what that could be related too. There were some slight changes in the sun/sky system, but nothing that would be that pronounced, and it doesn't even look like you had them in the scene. My only real guess would be that the light had a different lighting unit associated with them. These are new with the SR and all the old lights should have the Scalar unit associated with them

2) If you suppress the dialog box when you save (type -Save) then you will get several options in the command line. One of the options will be SavePluginData. If you switch that to No you should be able to open files made with the beta in a previous version.

I'm not sure what will happen with this behaviour once the SR actually gets released, but hopefully it will not act as such.

[Micha_cg]

Re: ****Please Post All V-Ray for Rhino 4.0 v1.0 SR1 Beta bugs here.****

My impression is: in the past the physical sky and the phys cam was working with much light and the standard cam with low light values. Since the SR, old scenes are overexposured in some cases, because standard cam and phys cam are less different exposured now (very useful).
Most to fix the problem it helps to adjust the shutter/ISO of the phys cam or the multiplier (color mapping options) for the default cam (or you turn down all lights in the same relation).
I don't know the details about it, I only know, it helps to adjust the cameras.

[Micha_cg]

Re: ****Please Post All V-Ray for Rhino 4.0 v1.0 SR1 Beta bugs here.****

If I set a color of a directional light, than this color is shown at the shadow color field too, but if I click on the shadow color, it's right at default black - only a UI bug.

[Micha_cg]

Re: ****Please Post All V-Ray for Rhino 4.0 v1.0 SR1 Beta bugs here.****

Critical RC bug: spot lights are reset to default values after reopen a scene. Workaround: note all values and set it again after reopen. :

[Gijs]

Re: ****Please Post All V-Ray for Rhino 4.0 v1.0 SR1 Beta bugs here.****

I am not sure if this has not yet been reported, because I cannot seem to find it quickly, but somehow I remember this bug to be an old one:

when inverting a map with the invert checkbox, after reopening the dialog, the multiplier is switched back to 1.

two material issues:

when a vray material has been assigned to an object, and you want to temporarily switch to a basic material, click on basic radio button, change material properties, it seems to stick until a rendering is made, it will switch back to using the assigned plugin material. The only way that works is to assign 'none' from the material browser first, then assign a basic material.

limitation with regard to materials (quite annoying in terms of workflow) is that material assignments are not recorded as a change and therefore cannot be undone.

[Gijs]

Re: ****Please Post All V-Ray for Rhino 4.0 v1.0 SR1 Beta bugs here.****

another critical one:

shader type: phong or blinn: when you change it in one material, it changes in the other materials too

but hey, if that is possible, why not make a feature of it: make changes across several materials at once, by multi-selecting materials. That would be a handy time saving feature.

EDIT: PLEASE FIX: anisotropy settings are erased when changing to phong. better erase that RC behind the build... all my precious materials are being destroyed :

[andreas]

Re: ****Please Post All V-Ray for Rhino 4.0 v1.0 SR1 Beta bugs here.****

Hello Gijs, Micha,

Just a question: since there is no official thread for the latest SR1 release candidate released at February 20th, I suppose the issues you posted here are in the release candidate version and not in the SR beta Version (this thread used to be about) of February the 5th? Am I right?

I am confused

Andy

[Gijs]

Re: ****Please Post All V-Ray for Rhino 4.0 v1.0 SR1 Beta bugs here.****

as far as I'm concerned, yes, I have installed the latest beta. Although it is RC, it is still the same beta, so that's probably the reason for not a new thread.

btw: are you still on the previous beta, can you check if those issues above are in the previous beta as well?

[andreas]

Re: ****Please Post All V-Ray for Rhino 4.0 v1.0 SR1 Beta bugs here.****

as far as I'm concerned, yes, I have installed the latest beta. Although it is RC, it is still the same beta, so that's probably the reason for not a new thread.

btw: are you still on the previous beta, can you check if those issues above are in the previous beta as well?

well, sorry i have also the latest Version (the RC) installed, I can however try to recreate and confirm the problems you are having... i will be back with this later...

Andy

[Micha_cg]

Re: ****Please Post All V-Ray for Rhino 4.0 v1.0 SR1 Beta bugs here.****

EDIT: PLEASE FIX: anisotropy settings are erased when changing to phong. better erase that RC behind the build... all my precious materials are being destroyed :

To avoid critical changes on my project file, I use this button script often:
!-_incrementalsave savesmall=yes _enter

So, if materials are lost or destroyed, than I can try to load it from an old file. Sidenote: no material lost since a long time, this problem seems to be fixed now.

PS: I would cancel the "RC" too.

[dkendig]

Re: ****Please Post All V-Ray for Rhino 4.0 v1.0 SR1 Beta bugs here.****

Hello,

I just thought I'd post this here, because it is rather important. This was posted in the announcements forum when we announced the release of the latest Service Releases for both V-Ray for Rhino and V-Ray for SketchUp. The post can be found here:

http://asgvis.com/index.php?option=c...0&topic=3554.0

and here

http://asgvis.com/index.php?option=c...0&topic=3555.0

I'll repeat it again now, to save everyone an extra click:

With this update, we have made changes to our support process. We have begun to implement a more efficient bug tracking process. In the past we would just create a "bug thread", and ask that users post any technical questions or concerns in that thread. This was an easy way to collect a list of bugs, but it was not very useful when it came to actually fixing them. Our new support and bug tracking system allows us to address questions and concerns much faster, and much easier than our previous method.

If you have any technical questions or concerns, please follow these simple instructions:


Quote
1. Click "Support" at the top of the site. You will then be taken to a page that will give you links to our Knowledgebase and User Forums, as well as a new option to "Contact Our Support Team".

2. Click on "Contact Our Support Team". You will be taken to a page that will have links for Technical Support and Feature Requests for each of our products.

3. Click on " V-Ray for Rhino Technical Support" or "V-Ray for Sketchup Technical Support". You will be taken to a page with a form, and some simple instructions that explain what information we will need from you, in order to best answer your questions. We would also like to note, that the links that you see for Feature Requests, will not put you in contact with the correct support team. This is intended for requesting new features in our products only.

The question has come up a couple times "why did you change the way you track bugs??". The answer is quite simple really. Our new bug tracking software, allows us to seamlessly integrate bug reports with our development process. So the exact moment you send us a bug report, our developers recieve the bug report, and it actually shows up in Visual Studio, as they're developing. This means there are some HUGE benefits. What kind of benefits?

1. The developers actually see the bugs you're reporting.
2. Faster response times.
3. You can see the status of a bug you report.
4. You have a more direct line of communication with the developers, and our development process.
5. Related bugs and trends are easier to see, which makes a much more efficient workflow for our developers.

That's just to name a few.

In the past, we used "bug threads" on our forum, just like this thread, to track bugs. There's a number of problems with this method of bug tracking.

1. If someone posts a bug, other users that may be experiencing similar problems, may think that their bugs are related, when in fact, they are NOT related. Unfortunately, unless you have access to the source code, and are able to debug our application, there's no way for anyone to be 100% sure that bugs are related. The more bug reports we get, from as many people as possible, the better chance we have of tracking down a bug and fixing it. If someone says "when I click this button it crashes", that doesn't really help. But if we get 50 bug reports from a variety of users, on multiple operating systems, and they all explain the situation in a slightly different way, we might end up with enough clues to actually figure out what's wrong.

2. Bugs get lost on the forums, they get buried under pages and pages of opinions, feature requests, idle chit chat, and work arounds. The forums are designed so that our users can communicate with each other, so these things are perfectly fine to do on the forums. Bugs on the other hand... those need to be sent to our developers. If our developers spend all day looking through the forums, trying to figure out what is a feature request, and what is an actual bug, they'll never get anything done. Bug tracking software allows us to separate the diagnostic information that we need in order to fix an issue, from regular conversation. Again, we're not saying that you shouldn't communicate to each other about issues, we're just saying that if you have a bug, and you don't submit it through our bug tracking software, it makes it very difficult for our developers to efficiently resolve any issues.

3. We recieve support emails, support questions on the forums, bug submissions via email, bug submissiosn via the forums, how-to questions, feature requests, sales questions, general inqueries, and so on, all the time. The biggest problem is keeping track of everything. We have most things separated out. For instance, if you have a sales question, you're probably not going to ask it in a bug thread on the forum. Likewise, you're probably not going to ask our sales people about support questions. As we grow and expand, we need to make sure that information continues to flow through the proper channels. At this point, we have determined that having bugs listed in our forums, is just not working. Too many times, has a bug slipped through our fingers due to lack of information, or a bug being posted in some odd place on our forums, or for whatever other reason. We have spent months researching and then implementing a more efficient, and streamlined way to track bugs. We now have the solution, and it is in place.


Again, we're not trying to stop all of you from communicating with each other about issues, workarounds, etc. All we're asking, is if you find a bug, PLEASE submit it through the proper channels.

Thank You,

Devin Kendig
Developer
ASGvis LLC.

[joe_b]

Re: ****Please Post All V-Ray for Rhino 4.0 v1.0 SR1 Beta bugs here.****

Only an idea: what is, if you copy the ASGvis folder from the master to the slaves and you setup the license server at the master?

Use the installer to install DRSpawner. Do not copy files. Make sure the previous DRSpawner is COMPLETELY removed ( you may have to manually check due to a glitch in the installshield project ). Then run the installer and install the new DRSpawner. The new DRSpawner is using a new licensing scheme so each node does NOT need to be licensed.

[joe_b]

Re: ****Please Post All V-Ray for Rhino 4.0 v1.0 SR1 Beta bugs here.****

So, if materials are lost or destroyed, than I can try to load it from an old file. Sidenote: no material lost since a long time, this problem seems to be fixed now.

Yes the material issue you are referring to was fixed for the RC. It was related to a mistake in the serialization process that would skip every 1 in 4092 bytes...this was enough to screw up materials.

[dkendig]

Re: ****Please Post All V-Ray for Rhino 4.0 v1.0 SR1 Beta bugs here.****

To give you an idea of how much I had to drop the settings.
I hade to change my light intensity / multiplier from 2 down to 0.003, and drop my physical camera settings as well.
This was using the scalar units; it’s like what Renee mentioned it seems to lose its settings or something when you re-open the file.
Mark

We have been able to confirm a bug with the spotlight, and are working to fix that issue. I'm curious if the issue that you've been experiencing with over exposure only happens with spotlights, or if it happens with other lighting setups too. If you could, please submit this issue to our bug tracking system by following the instructions mentioned earlier in this thread. In your bug submission, please describe the lighting setup that you have in your scene. If we are unable to reproduce it, an example scene file may be of help too. When you submit the bug, instructions for sending us an example scene will be in the automatic response you will get.

Thank you,

Devin Kendig
Developer
ASGvis LLC.