Archived Old Bugs

[Micha_cg]

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

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

Hmm, 50 x 5 min writing a bug report = 250 min man power for report a single bug only? I hope you forget to write, that all users can read the bug list and must not write bugs again and again.

[joe_b]

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

Hmm, 50 x 5 min writing a bug report = 250 min man power for report a single bug only? I hope you forget to write, that all users can read the bug list and must not write bugs again and again.

People word bug reports differently, can have additional information to provide, can have different ways to make a bug happen. All of this helps us get our job done quicker. A single report is not always sufficient to help us do our jobs. Since users are not aware of how things work in our code they are not fully able to determine whether bugs are related or not. Sometimes similar effects can be caused by completely separate issues.

We do not want users censoring themselves because they think the bug has already been reported. In the end it is counter-productive.

[dkendig]

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

Agreed

[Micha_cg]

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

If a bug can't be catched by the developing team, than it could be marked as "more infos needed" at the bug list and user could help per more reports.
Why should 20 users post - "if I reopen a Rhino file, all spot lights are reset, also if I copy spotlights" (current RC bug)?

I understand, that some crash bugs are difficult to catch. But if other users could read the bug report, than critical effects could be tested by the community and so, the developing team could get more help too. For example the material match issue, if materials are assigned per "browse" material properties button.
And if a bug is very seldom, than it dosn't help, to don't post in a list.

Or people are hard trying to get a render effect - a short look at the bug list - ah, it's a known bug, not users fault, let it be know.

EDIT: I would prefer a system like this
http://asgvis.com/index.php?option=c...90&topic=447.0

[andreas]

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

Hello everyone,

i really think you thought long and hard about this so please excuse if i may not see all the problems involved in bughunting / development but
maybe there could be a kind of compromise here, there could be a list which contains the current known bugs, published on a daily basis by the developers of asgvis, that would guarantee that the published bugs are really bugs and would be a dependable source to all users to look at if they have any problems. That list could also contain infos for users and developers who are actively bug hunting like Micha said e.g. "already fixed for the next release" or "we need infos if XY also happens on windows XP" or "who could repead this - please state OS, cpu, ram etc"

just a thought

Andy

[dkendig]

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

Hello,

At the moment, we do not have the resources to accommodate this request. In time, we may start publishing a list like that, but right now, a list of this sort is not helping the development process, and is actually making bug tracking more difficult. We understand what you're telling us, but it's just not something that are able to do at the moment.

Here's the big picture, we want to fix the bugs. If we fix all the bugs, a bug list won't be needed. If you want to know what was fixed, look at the change log in the read me file that comes with the installer. We understand your concerns, and we hope that this won't cause too much of an issue with anyone's workflow. If it becomes a huge issue in the future, we'll cross that bridge when we get there. At the moment, the main focus is to have our developers dedicated to developing, and not doing other things. I hope you all can understand.

Thanks

[Gijs]

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

fair enough Devin. I did not know about that new bug reporting system, so I will use that from now on. Better change the forum topic to problems instead of bugs then, just like on the chaos Vray forum

[dkendig]

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

Thanks for understanding Gijs, we know we're not perfect, but we're striving to improve things around here. There will be some changes with the forums in the near future, but we haven't quite decided on the best plan of action. We've spent the past couple of days going through the forums, trying to create cases in our bug tracking software for each unique bug we find, and there's some issues we would like some more information on, before we start reorganizing things in our forums.

[Micha_cg]

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

Bug is reported by new system and here the workaround. Problem: the mapping of blocks isn't fixed to blocked objects, move the block object and the mapping is wrong. What helps? Assign mapping to an object -> extract rendermesh -> export this mesh as obj -> reimport it -> ready for use as block.
The mesh->obj->reimport cause, that the mapping is baked in the mesh and will not be lost by move.

[Micha_cg]

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

Hi development team, is it possible to send bugs per email too, because it would make it easy to attach files? Maybe the bug tracking system works with email too.

I will report per new system later: bump mapping seen in reflections is shown inverted.

[dkendig]

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

Hello,

For the most part, we would prefer that everyone use our contact form, at least the first time that they contact us for support. Mainly because on the submission page, we explain what we need before we can answer a question. Spam control is a concern as well. If we post the email address on the site, instead of having it submitted through a form, spam bots can and will crawl our site and find the support email addresses, and begin spamming the inbox like crazy. (This was a minor issue with our old support email address). Another reason we prefer this method, is that it ensures that the support requests are going to the correct department (V-Ray for Rhino Support, V-Ray for Rhino Feature Requests, V-Ray for Sketchup Support, etc).

There have been a number of "bugs" that have been submitted to us in the past, that were not bugs at all. Instead, they were requests for new features, or workflow changes. These types of requests should now be submitted using the appropriate "Feature Request" form. That way our developers can focus on existing problems first, and then add in additional features later. So again, using our contact form, ensures that you're sending this type of request to the appropriate place.

So that's a couple of the reasons we prefer that people contact us using that form on our support page, instead of just sending us an email. Of course, there are special exceptions. Some of you test our product regularly, and send us constant feedback about the product. For those of you that do this, filling out the form and then replying to the email, could hinder the testing process. What we recommend in this case, is that you use our support form at least once, then afterwards, you should get a reply email. This email that you receive should have the support email address for that product. If you send an email to that email address, a new support ticket will be created, just as if it was created using the form on our support page. All that we ask is that you follow the same guidelines that you would use when using the form on our support page. Also, we ask that you not attach any files to an email that are larger than 10mb in size.

In short:
-We ask that everyone submit support requests by using the form on our support page.
-Email submission of bugs can be done, the email address can be obtained by using our form on our support page at least once.