Archived Old Bugs

[joe_b]

**** PLEASE POST ALL VFR4 PROBLEMS HERE *****

This should be where we post the issues with our official release of VfR4 1.0 - thanks all

[smail]

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

DISTRIBUTED RENDERING
So I have solved my problem with run the DRSpawner.exe so I try to use distributed rendering. But the outcome from that wasn't realy good. I posted two images - first image (faster) was rendered by distributed rendering, second image was rendered by one computer.





As you can see at the first image there are many bug places. Both images were render by same rendering options - IM + LC, physical camera.

Rhino 4 with VRFR4 runs on WIN XP Home 32bit, Pentium M 1.5.
Render Slave (DRSpawner) runs on WIN XP Pro 32bit, Athlon64 3500+.
Thanks for reply!
Smail

[joe_b]

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

Could you send me the scene please? It appears the light positions are incorrect or something along those lines. Thanks.

[Micha_cg]

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

Missing feature of previous versions: if I copy and past an object from an other Rhino scene, for example a 3D people, than the material texture preview show me the texture, but if I click on the path ("M"), because I want to change the texture from people1.png to people1b.png (other cloth colors), than the texture wake up in the wrong directory (last used Rhino dir) and dosn't show me the name of the current texture. So it's difficult to know, what was the name of the texture and where was it located.

[andreas]

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

Hello Newsgroup,

i have already mailed that one to the asgvis team, however I wonder if anyone can verify this :

After I reinstalled the latest version of vray4rhino, my vray-materials do not show transparency in my viewports anymore (e.g. the clear glass from the library). When I switch to the basic rhino material the transparency value is 0 ( I think normally this should inherit the transparency value from the vray material)…

Can anyone repeat this?

Best regards

Andy

[andreas]

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

Hello newsgroup,

since it is a very, very important feature for me, I am testing the DR function quite excessively. Some thing that I observed so far:

1. Sometimes the computer I work on looses connection to our server while doing a DR rendering. I have no idea why but it occurs only during DR and even after I abort the rendering and close rhino I am unable to reconnect so right now I have to reboot my computer to continue work.

2.sometimes on or more of the render slaves simply stop to render, the dos box text says "clearing color mapper"

3.sometimes, when changing the scene lightning on my computer the information is not communicated to the slaves, so right now to be sure this does not happen I restart the spawner Program on each slave before DR.

can anyone repead this?

best regards

Andy

[smail]

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

Could you send me the scene please? It appears the light positions are incorrect or something along those lines. Thanks.

Hi Joe, I sent the scene to you by personal message. Thanks. Smail

[Micha_cg]

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

Does the DR work, if I use XP64 and the slaves are XP32?

[merlik585]

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

Hello newsgroup,

since it is a very, very important feature for me, I am testing the DR function quite excessively. Some thing that I observed so far:

1. Sometimes the computer I work on looses connection to our server while doing a DR rendering. I have no idea why but it occurs only during DR and even after I abort the rendering and close rhino I am unable to reconnect so right now I have to reboot my computer to continue work.

2.sometimes on or more of the render slaves simply stop to render, the dos box text says "clearing color mapper"

3.sometimes, when changing the scene lightning on my computer the information is not communicated to the slaves, so right now to be sure this does not happen I restart the spawner Program on each slave before DR.

can anyone repead this?

best regards

Andy

Number 1 and 2 I have not seen,number 3 something similar if I edit a material to change a path for a map on the master,(the path is now the same on both computers)even if I restart the spawner,the changes does not appear on the slave and it can't find the map.

Renee

[merlik585]

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

This one I am not sure it is a bug,but it took me sometime to figure it out.

If you assign a sky to a material to get a different reflection,any changes you do to the lighting set up does not work.I found that out by
finally thinking of overriding the materials set up,the sun and sky started to work again.if it is not a bug,may be it should not be allowed to set a sky as a reflection environment for material.


Renee

[joe_b]

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

Sorry for the delay in my response guys - I've been working at a deadline. Let me combine my responses here.

than the texture wake up in the wrong directory (last used Rhino dir) and dosn't show me the name of the current texture.

interesting - I'll check that out.

@VCube
I'll check out the transparency issue

As for DR - I've noticed that sometimes the nodes need to be restarted - it seems they just kind of hang for some reason or another. I'll look into it further but as of now I'm not sure if it something we're doing or something on the V-Ray side.

Is there any particular lighting you change that doesn't seem to get sent properly to the render slaves? And when you start fresh does the lighting send ok?

@RVallieres
I'll have to try that map issue. One thing I'm adding for the VfS is a means of "asset collection" where it will send each texture to the render slaves, or to a shared folder automatically. This will be available in VfR as soon as we do a patch. I guess that will resolve that issue - though I'm unsure why the path change would not be reflected in the dr scene.

@Micha
I believe the 64/32bit issue was resolved in a previous SDK. So yes, I think it should work.

[andreas]

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

@VCube
I'll check out the transparency issue

As for DR - I've noticed that sometimes the nodes need to be restarted - it seems they just kind of hang for some reason or another. I'll look into it further but as of now I'm not sure if it something we're doing or something on the V-Ray side.

Is there any particular lighting you change that doesn't seem to get sent properly to the render slaves? And when you start fresh does the lighting send ok?

Hello Joe,

In my case it was actually a direct light, to be precise a sunlight system set to manual. I also noticed that when I gave my sun a name, this is often not displayed correctly in the vray environment dialogue where you link your sky with a particular light. For example I named my suns "outside-01" and "inside-01" but in the dialogue i was referring to it still reads "light1" and "light2"...

The light bug is not repeatable, but occurs sometimes. I have not found a pattern yet. By deleting not used lights and restarting the slaves I try to avoid the trouble, but right now my biggest concern is that especially when doing more complex scenes I usually everytime experience hangups by the slaves or my "work" computer disconnects from our server/LAN. This leaves the great, great DR function very unreliable for me right now. To reconnect to the LAN I have to deactivate the network connection (which windows still reports as working) and then reconnect.

As you might have noticed I am a very big fan of DR
I am able to speed up my rendertimes by 6! That really means a lot of stress relief for deadlines and more sleep for me, so I hope you find the bug if it is vray that causes the problem. I also did DR with vray for 3D Studio where these problems did not occur, so I doubt it is vray alone (no offense intended)

best regards and keep on the great work


Andy

[smail]

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

Distrubuted rendering ???
Hi, I have made some other testing of DR, and I discovered that the model has to be in "cm" units (not in "mm" units) and also it has to be near origin, because if not the render has got many bug fields with different brightness/constrast from render slave(s) or master.
And at my last tests you can see that last bug is with the Sun. At the distributed render there are something like two suns. One is vertical - calculated by slave (you can see that under the holes in roof), and the second normal sun - calculated by master. At the single render there is only one source of sun.





Have a nice day. Smail

[joe_b]

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

In my case it was actually a direct light, to be precise a sunlight system set to manual. I also noticed that when I gave my sun a name, this is often not displayed correctly in the vray environment dialogue where you link your sky with a particular light. For example I named my suns "outside-01" and "inside-01" but in the dialogue i was referring to it still reads "light1" and "light2"...

Yes I've noticed that sun light naming issue. That should be easy enough to fix

The light bug is not repeatable, but occurs sometimes. I have not found a pattern yet. By deleting not used lights and restarting the slaves I try to avoid the trouble, but right now my biggest concern is that especially when doing more complex scenes I usually everytime experience hangups by the slaves or my "work" computer disconnects from our server/LAN. This leaves the great, great DR function very unreliable for me right now. To reconnect to the LAN I have to deactivate the network connection (which windows still reports as working) and then reconnect.

We'll have to do some more heavy testing around the office to see if we can determine the cause of these hanging problems. They appear to be random - but there must be a reason.

I also did DR with vray for 3D Studio where these problems did not occur, so I doubt it is vray alone (no offense intended)

Yeah - we've done some testing on the 3dsmax side and also haven't had a repeat on this hanging

Hi, I have made some other testing of DR, and I discovered that the model has to be in "cm" units (not in "mm" units) and also it has to be near origin, because if not the render has got many bug fields with different brightness/constrast from render slave(s) or master.
And at my last tests you can see that last bug is with the Sun. At the distributed render there are something like two suns. One is vertical - calculated by slave (you can see that under the holes in roof), and the second normal sun - calculated by master. At the single render there is only one source of sun.

Thanks for the help- it is interesting you bring up the scale problems - I'm pretty sure we do convert all the necessary units properly (the physical camera focal length / film width needs to be translated to scene units for the calculations to be correct ). But perhaps I've missed one. It seems other people are also having issues with lighting not getting sent properly in certain cases. I'll see what I can figure out, thanks again.

[andreas]

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

Hello Newsgroup,

some more DR testing:

I am not 100% sure about this, but the hanging of slaves might have something to do with additional alpha channels being rendered like e.g. raw GI, shadows and so on.
Since DR does not support additional channels right now (apart from z buffer?), there is no reason to have them anyway, mine were a leftover from an older test run, so I was not aware they were still there.

I am testing a scene right now, where I had hangups of slaves nearly every time after 20 minutes or so, the last 2 times I rendered without the channels I got no hangups after 5 hours of rendering...

best regards

Andy