Archived Old Bugs

[dalomar_cg]

Re: **** PLEASE POST ALL VFR4 PROBLEMS HERE *****

Did you make sure that you're bitmap is mapped via environment mapping as opposed to regular UVW mapping. I've seen that a number of times when I've for gotten to do that.

[boo]

Re: **** PLEASE POST ALL VFR4 PROBLEMS HERE *****

Ok, I found out how to avoid having these artifacts appear in my rendering. The problem was related to distributed rendering. It seems the other slave machines could not find the .hdr images being used on the master machine to create the rendering. So I created a c:\hdr directory on the master and slave machines and copied the required hdr files there. Then the rendering worked fine.

[Micha_cg]

Re: **** PLEASE POST ALL VFR4 PROBLEMS HERE *****

Hi, it's so quite here the last days. So, I post a bug report.

I try to render parallel views (front, left, top, ...), but the rendering dosn't match the viewport, it's totaly different. The rendering show the object very small only, it looks zoomed out. I thought, it was working in the past. My current workaround is to set a perspective rendering with 500mm lens. But a working parallel rendering would be better.

[smail]

Re: **** PLEASE POST ALL VFR4 PROBLEMS HERE *****

Hi, it's so quite here the last days. So, I post a bug report.

I try to render parallel views (front, left, top, ...), but the rendering dosn't match the viewport, it's totaly different. The rendering show the object very small only, it looks zoomed out. I thought, it was working in the past. My current workaround is to set a perspective rendering with 500mm lens. But a working parallel rendering would be better.

Hi Micha, you will have got this problem if you use physical camera... if you try to use standard camera the TOP view render will be the same as you see in rhino viewport. The problem is if you switch from physical camera to standard you also have to redefined all light/emitters... :-\
I hope that it will help you. smail

[Micha_cg]

Re: **** PLEASE POST ALL VFR4 PROBLEMS HERE *****

Oh, thats bad. Joe, is it possible to fix it?

Thanks, smail. For you it should help to set a low multiplier at the color mapping options at 0.0001 or something like this. So you should get the same exposure like with phys cam.

[dalomar_cg]

Re: **** PLEASE POST ALL VFR4 PROBLEMS HERE *****

Hi, it's so quite here the last days. So, I post a bug report. Wink

It has been quiet...giving me more time to test internal builds

Well since parallel projections are not physical, so I'm not sure if that could be added to the physical camera... and if it could I believe thats something for Vlado since that functionality would have to be added on his end (I think).

[Micha_cg]

Re: **** PLEASE POST ALL VFR4 PROBLEMS HERE *****

"Are you sure you want to remove this material from the scene?" - strange question if the material is not assigned to any object in the scene. I'm confused everytime. Better would be to ask "... remove from the material manager" if it is not used at any object.

[Micha_cg]

Re: **** PLEASE POST ALL VFR4 PROBLEMS HERE *****

Some problems today:

- if I set affect shadow of a glass material, than it's not taken in acount for GI environments. Could be nice, if refractive caustic must not be used and GI can use the transparency shadow too. (Could be a general Vray engine bug)

- Global option "disable maps" disable environment HDRIs too. Could be nice if the HDRI could stay, because "disable maps" is good for fast previews, but without light ...
Better would be, if the user need to disable HDRIs too, he could disable the usage of env texture "M" only. But this is the old wish again to disable maps temporary.

- And now a right bug, not so a "bug&wish": I can use jpgs in grey format for diffuse and bump, but not for fresnel reflection control. I needed some time to find the reason, why my reflections maps dosn't work. Converted to RGB it works allways, but it should work in GREY too. The great Arroway.de textures use grey often and other collections too.

[dalomar_cg]

Re: **** PLEASE POST ALL VFR4 PROBLEMS HERE *****

1. This is (I think) because the affect shadows result is calculated directly at render time, and is not actually adding "illumination" but changing the shadows.

2. Agreed

3. Okay...another thing to look into.

[Micha_cg]

Re: **** PLEASE POST ALL VFR4 PROBLEMS HERE *****

1. If it is not a bug, than let it be a wish please. The GI calculation could handle glass with "affect shadow" like an opac material with transparency (like it do the standard light calculation). Please ask Vlado, it could be nice to get the affect shadow working for any light source.

[keijun]

Re: ***PLEASE POST ALL V-Ray for Rhino 1.0 BUGS HERE***

Because of the light problem, I install 'V-Ray for Rhinoceros UI Dependencies' after install vray 1.0 for Rhino 4.0

before install that program, light multiplier value have to be more than 100

but after installing, value 1 is sufficient(similar with previous value 100)

However, after install Rhino 4.0 SR2 RC3 to upgrade, UI Dependencies go back previous state(light value have to be more than 100 to recognize)

I don't know about this problem from which program. rhino? or vray?

Please support and fix this problem

Thank you and sorry for my poor English.

[Micha_cg]

Re: **** PLEASE POST ALL VFR4 PROBLEMS HERE *****

I'm working on a detailed modell of a display. I like to use the same studio setup for different view, so I fix the camera and copy/turn the model. So I used four models. My problem is, that the material editor massiv slow down, it's inpossible to rename a material without to wait several minutes - Rhino is freezed. I feel, the material editor check all assigned materials and model surfaces and need a long time. It's not the first time, that the material editor works slow.
Joe, maybe you know what I mean. Maybe there is an algorithm, that could be optimized.

[pu235]

Faulty Render Buckets. Why?

Hi,

could you please have a look at the attached image. Some buckets seem to render faulty.



The file was rendered distributed via a LAN cable between a Pentium Single Core and a Pentium Dual Core (Both around 1.7 GHz and each with a Gig of RAM).

Absolute identical materials were available on the Z drive of each machine (=Two USB sticks).

Can it have an influence, if one of the computers has been used for Rhino modelling in parallel?

Normaly that should not be the problem.

Any ideas, how to get rid of this problem?

Thanks & regards,

Charlie

[dalomar_cg]

Re: **** PLEASE POST ALL VFR4 PROBLEMS HERE *****

Yea, if its a DR thing then chances are we've got it. For the new SR Joe has gone through an overhauled a lot of the issues that were happening with Distributed Rendering. Sorry for the inconvience...the new SR should be available in a few weeks time.

[Micha_cg]

Re: **** PLEASE POST ALL VFR4 PROBLEMS HERE *****

I never have seen something like this, but maybe your calculation based on saved GI cache files and this file are missed at the slave. Some times the slave progress window tell more.