If you are unsure how to proceed with instructions you received from our support department, please ask our support department for more details. We even will offer to remotely log in to your computer and fix it for you if we are unable to resolve the issue by providing you with instructions.

@unknownuser said:

Don't buy the app (or any other app, for that matter) without trying it out extensively first.

I completely agree with this statement. There is a somewhat difficult learning curve that comes with our product, mainly because of lack of documentation. We will be addressing some of the limitations and bugs that are in this current release in our next development cycle, but until we can address those issues, there are workarounds, as andybot (thanks!) mentioned. Of course the next version is always going to be better, so try out the demo, if you like it, cool, if not, we'll try to get you next time

We won't have a new version of V-Ray for SketchUp out for at least a couple of months. We are finishing up development on V-Ray for Rhino some time in the next month, and then we can begin planning our next development cycle. We are aiming to have simultaneous development for both products with this next development cycle.

In the future it will be easier to roll out patches with bug fixes, now that both products are using the same core. There were some modifications we had to make to our plugin in order for it to work with Rhino, that made it not possible to quickly migrate the changes back to VfS, at the beginning of VfR development. This made it very difficult to migrate the changes back without making a handful of somewhat big changes first. Since VfR development was supposed to take 3-6 months, we didn't think that would be an extremely long wait for a new VfS patch. We were just going to hold off on making the big changes to VfS so we could get VfR up to speed with the recent plugin rewrite. Then we were going to take all of the bug fixes from the VfR development cycle and apply them to VfS. Unfortunately the demand for certain features in VfR required us to make some changes that we did not originally plan for, and between that and the growing pains of the acquisition, our development cycle has taken longer than originally expected.

All being said, I think that this past development cycle has been our best one yet. We managed to tackle a lot of nasty bugs, and add some very powerful features. I can't wait to share those changes with the VfS community! With that being said, off to work I go.

We haven't figured out a way to do that yet with our setup, but if we ever do, I'll let ya know

... I don't understand how that could be the case, but then again... when has that ever stopped a bug from happening? I'll circle back to this when we are in SketchUp land again.

Holmes - The company acquisition process took a while, I can't remember how long. CG wanted us to put out a new version of our products as soon as possible, as did we. Both user groups waited a very long time for those updates. VfR production began when we were under the impression that VfS was stable. We didn't discover just how unstable the current version was until we were already under way with VfR development. The plan was to have VfR finished within 3-6 months, rather than a year, so the decision to halt development at that point and put out a VfS patch didn't seem too appealing at the time. We would be finished VfR soon, and then circle back to VfS to take out the rest of the bugs.

There were more issues than expected, quite a few of which were also present in VfS. As we fixed issues in VfR, some were fixed in VfS as well. These fixes have been waiting to be integrated in to a new build of VfS. We don't separate bug fixes from features, a change is a change. So we don't really have a way to make a new build of VfS that doesn't have Dispersion, or RT at the moment. Since some of the changes rely on some host application specific related code, some of those changes will just break VfS entirely until we are able to add in the host application functionality that we need in order for the changes to work properly. There are some other really boring technical things I can talk about too, but I would like to summarize by just saying that there are some things preventing us from just putting out a new build of VfS without putting in a good bit of work unfortunately.

We don't have the time/resources to spend on that at the moment, but as soon as we do, we will put out a build that will address as many of the reported issues as possible. I understand that VfS users are facing some bugs that prevent them from being able to use the product fully and as effectively as they would be able to with those bugs fixed, which I agree is not a good situation. We have some Rhino users that have been waiting a couple of years for some of their bugs to be addressed though, so we can't really spend a couple of weeks (at the end of this development cycle especially) trying to get a new build of VfS out the door. It isn't that we don't care about our VfS users, as I've stated before. 3 or so years of a wait for a new build of VfR was just too much, and we really didn't expect this development cycle to take so long. The goal was to have a new VfR build out the door within a couple of months, and then immediately follow up with an update for VfS that would address the bugs fixed during VfR development, thus making both products even and ready for simultaneous development.

@unknownuser said:

Is your next design cycle to fix bugs in the existing VR4SU?

Our next cycle should hopefully address both products simultaneously. If we are unable to accomplish that, then yes, VfS should be next. We haven't been told that we are going to be reassigned or given another product to work with, so VfS and VfR should be the only two products on our plate for the foreseeable future at the USA office.

@unknownuser said:

Does that start as soon as VR4R 1.5 is rolled out? (Becomes a paid product)

The planning and initial assessment phase, yes. Don't expect VfS beta to start the day after VfR gets officially released!

@unknownuser said:

Are you still on track to roll out VR4R at the end of Feb? (which is now)

We have extended our beta testing phase an additional month, but we are trying to finish up prior to that if possible. There are some issues that need to be addressed in a release, and some that can be handled with a patch. We aren't going to wait until every known bug is fixed prior to releasing, that's not a realistic goal, but we do have some that need to be addressed.

I'm sorry I can't pick an actual date to give you to work with. Well I could, but it's a silly and frustrating game to play, so I'd rather not. I just go by the number of critical bugs that are in our bug tracker. Currently there are about 30 or so left to tackle before we release. How long will that take? I just fixed a duplicate sun issue that only occurs during the upgrade process from 1.05.29 (.30 for vfs). I thought it would take a day at most... Then my work machine's motherboard got fried... then the issue ended up being fairly confusing and complicated... so it actually ended up taking 2-3 days, plus almost a work week of downtime while getting a new machine and setting it up for development. ::shrugs:: That's EXACTLY why I don't pick dates.

We are fully aware that we make a tool that is used by professionals in a production environment. Even though SketchUp is inexpensive (or free), that doesn't mean it isn't relied upon just as heavily as any other visualization tool. We look forward to providing you with a better tool than what you currently have, so that we can all be productive and successful.

in Windows, it should be a little different. On Mac, you don't have to copy and paste from one instance of SU to another to cause a problem, all you have to do is just create and/or use materials in each instance independently. If you'll notice, the original poster said all they have to do is open another scene in another instance to cause a problem. This is not the case in Windows, you would need to make the two instances interact somehow before there would be a problem... or at least that's where I last left off with this issue... If it has mutated in to something more awful... please let us know...

I'm glad you haven't given up hope. I know we can kind of vanish in to a black hole from time to time... but that typically means we're busy, rather than what everyone always seems to assume (WHERE DID THEY GO!!! THEY'RE GONE FOREVER!!! NOOOOO!!!!). We are still chugging along. I just wanted to pop in here and calm the masses a bit. Now off I go to fix a duplicate sunlight issue again! ::flies off in to the sunset::

This bug happens on Mac only, and is caused by a change in the way SU works on Mac vs Windows. On Mac, there is one instance of the app, meaning only one instance of our plugin is loaded. On windows, every SU windows is it's own instance, and a new instance of our plugin. The workaround proposed makes sense, because then the OS would treat the different copies of the SU app as different products, so they would each have their own instance of our plugin running.

@unknownuser said:

I'm sure this is true. However, surely there must've been a few windows of opportunity the past few years? VfSU being very buggy is hardly a recent phenomenon.

Yes, originally there was one developer. We grew to 4... and we're more productive now with 2 than we ever have been. We would love to find some more developers to add to the team, after this development cycle. We didn't have as many resources in the past as we do now, so that's going to play a big part in how much things are going to change. We rewrote our whole plugin in the last update, which brought about a lot of change already, and addressed many of the old bugs that existed in the previous version. I completely understand that it's hard to appreciate that when you are currently facing a new set of bugs that sprung up in this last release. I'm not interested in making excuses for the state the product is currently in, there are some nasty bugs that need to be addressed as soon as possible. The future looks promising, and I can't wait to see VfS with all of the new fixes and optimizations in place.

@unknownuser said:

That's very nice -no sarcasm intended. But when can we expect a point release that adresses the issues people are currently experiencing? It's really overdue, and I for one am becoming somewhat annoyed.

I could pick a date, but it won't mean anything. The most accurate comment I can make about this, is that we need to get VfR out the door prior to addressing VfS issues. It's not that you're lower on the totem pole or anything of that sort... it's just that the VfR guys have been waiting much, much, MUUUUCH longer for an update. It's their turn right now. We don't want to continue the pattern of only working on one product or the other, because it makes big fixes and patches go very slowly. Now that we have Chaos Group's resources on our side, we should be beginning simultaneous development after we finish up with this dev cycle. Please keep in mind that this is the plan, and will most likely be modified a few times before it finally comes to pass. It is the best roadmap or crystal ball I can provide at the moment.

Final Release of VfR -> Planning next dev cycle -> VfS and VfR development begins -> VfS and VfR Beta -> VfS and VfR Release.

@andybot said:

@stinkie - what really bugs me is that they have a bunch of bug fixes already done - Devin has said so in posts early last year. I would love to have a beta to play with too. (Hell, we're basically playing with a beta currently...)

We do have some sketchup-specific bug fixes that are waiting to go in to an installer, but those are just the tip of the iceberg. We have fixed and optimized all sorts of stuff since the VfS release. We will do our best to get as many fixes to you as soon as we can. We are trying to finish up with VfR asap.

@valerostudio said:

Enough said. [attachment=0:25fanj0l]<!-- ia0 -->forum screenshot.JPG<!-- ia0 -->[/attachment:25fanj0l]

That forum doesn't get used anymore, but the humor is not lost on me

We get that suggestion a lot "why don't you just hire more people". Unfortunately it's not quite that simple. You can't just toss a developer at our code in the middle or end of a development cycle, It takes time to get someone fully up to speed (and that's a developer time, not a training person's time, we don't have someone that just trains new developers). This is especially true when dealing with anything in SketchUp. We were acquired by CG about halfway through our development cycle. There were some changes that needed to take place after the acquisition, which naturally would occur after one company joins up with another, but for the most part, it wasn't a very bumpy road for long.

We will begin simultaneous development for our products soon. The additional resources will come in to play after this dev cycle. We appreciate the support from you guys. I don't think it's really fair to point the finger at CG about our current troubles though, we wouldn't be in too different of a situation if they weren't involved. I have to say that it's actually refreshing to hear people talk about trying to switch to another rendering solution, and then eventually come back and say that we are the better solution, even given the issues that made them want to switch. I know it encourages me to keep going, I don't know about anyone else. It makes me excited to hear what all of those users say once we actually resolve the issues they've been struggling with since our last release, and also see the amazing work they will create with a more stable and featured-packed product.

So with that said, thank you to everyone that has stayed with us, we look forward to making it worth the wait.

We aren't sure when the next development cycle will start, but now that the rewrite is up and running with both VfS and VfR, we will hopefully be able to handle simultaneous updates to both products. That would eliminate the catch-up period that we have between releases of each product, and shorten our development cycles considerably.

There is a V-Ray Lens Effect that will be added in the next release that will do this as well.

what version are you using, and where did you download it from?

Correct. We have to direct the license server to the folder where the licenses are, this bat file does exactly that.

Check the Applications/ASGvis folder, you should see an alias to run the DR Spawner. You MUST use this alias to run the DR Spawner or it will NOT work. Once it's running, you should be able to follow the instructions to use the DR Spawner during a render. It's the same on Mac as it is on PC. Also, when going to render a given scene for the first time, always check what machines are set to be used in the DR Spawner settings, and click the OK button when you are done reviewing them, just to be sure that the information you looked at gets used. We found a bug while working on V-Ray for Rhino, where the machines would not be used unless you looked at the servers that are set, and you click OK.

Yup, 359. 360 is the same point on a circle as 0.