Archived Old Bugs

[joe_b]

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

1) Transparency in Png file doesn't work, or work in some area
2) If texture name is over a certain amount of letters and with space, vray doesn 't show it in the viewport, and doesn't render it
3) Size of texture, I figured out that there is kind of limitation in the file size\ resolution of the texture

Could you send me sample textures that display these behaviors? Thanks

4) Can't use both at the same time texture multiplier in texture properties and in mapping properties

I'm not sure I follow what you mean by this. Could you maybe post a screenshot of what properties your referring to? I'm mainly not sure what you mean by the mapping multiplier.

not a real bug, but it's kind of hard to ashieve a 100% real white floor, without overburning color and light!, If someone have a magical solution, please tell me.

I believe no object will ever have a true white color - RGB(255,255,255) isn't something that an object will show in the real world. Just as no object is truly Black (RGB 0 0 0 ) either. Having the correct colors, as well as proper gamma and colormapping settings should allow you to get the white you are looking for without burning or oversaturation. Maybe Micha or Damien could explain more about that.

[Micha_cg]

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

White? I would say it's a question of exposure or intensity of the lights. For example you could use color value 230 for white allways. This is quite physical correct, because 255 means 100% diffuse reflection without absorbtion - not standrad at the real world, so a lower white value is better. A good standard real world white is at 80% reflectance.

So, if you use for example 230 for white and once you need a more white object, than you could use a higher value in special cases.

But the right gamma workflow is important for good images allways. Set input gamma at 2.2 and output at 2.2 or less or more. If you like more contrast, set output 2, if you like less contrast set 2.6.

Often I use the framebuffer controls to fineadjust the right birghtness and contrast. If you use the curve control only, than you can save the correction per right mouse button at the graph window.

[dalomar_cg]

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

A really easy way to tweek how white your whites are is Levels correction. You can do that in any image editing software you like, but I prefer doing it in the frame buffer so that there are no "gaps" in the histogram like you'll get if you do it after.

For Gamma correction I prefer to keep my output at 2.2 and inputs at 2.6. That give my colors/textures a bit more saturation/contrast.

[Micha_cg]

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

Damien, your method is very interesting - it helps to give textures more attention than the lighting. So, it's possible to get very light lighting effects, but powerful colors. And the other method, to use a lower output gamma give the lighting effects more power and textures/colors could be less intensiv. It's good to know about this two different ways to change the mood of a scene.

[dalomar_cg]

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

Personally, I prefer to adjust curves on a per channel basis, and for the framebuffer I'm kind of out of luck on that one. Besides, I try to keep a "balanced" histogram with the colors spanning from 0-255 or as close as possible (not for every situation, but it works well for most). Its easier to do that by adjusting the levels then to try to have every render come out like that. Its a Ansel Adams/photography concept, where you shoot an image for a narrow range of tones, then spread that range out to get more contrast.

With the gamma levels, the thing thats interesting is that once you start increasing the gamma value the difference between 2.2 and 2.6 is very little compared to a gamma value of 1.2 and 1.6. For me having the inputs at 2.6 darkens them just slightly more than they are corrected, which prevents them from looking too washed out. I haven't tried lowering the output gamma to get a bit of those colors back, so I'll try that and see what comes of it.

[Shopper2]

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

Name a material in the material editor:

eg:

Matte_black

now try and change the b of black to a capital letter... doesnt work?

Can u guys repeat this?

Justin

[Micha_cg]

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

Same here.

[joe_b]

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

Matte_black
now try and change the b of black to a capital letter... doesnt work?

Hmm - it must be a bug in my unique name checking stuff. Since I do case-insensitive comparisons I suppose it thinks you are trying to make another material with the same name, rather than realizing your just renaming an existing one.

To get around it you can probably just change the name to something else - then change it back

[mires]

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

hi everyone,

my problem is the frame buffers not saving the images in any format. I have also tried the render output save but it does not work too. there is no problem while saving the rhino's own renders but when i try to save the vfr4 v.1.00 it writes "error writing file". what might be the cause of the problem

and also one small detail. It would be nice to render dimensionings practically (i use rhino for industrial design renderings) but vfr4 does not render the dimensions unlike rhino s own render(although i assign vray materials to those dimensions). i guess this problem is about vfr.

[dalomar_cg]

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

Type SaveRenderWindowAs in the command line and see if that allows you to save your image. I'm not sure why our framebuffer is doing that, but see if that works and if it does, then at least you'll be able to save your renders in the time being.

[joe_b]

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

my problem is the frame buffers not saving the images in any format. I have also tried the render output save but it does not work too. there is no problem while saving the rhino's own renders but when i try to save the vfr4 v.1.00 it writes "error writing file". what might be the cause of the problem

You can't save ANY file type from the V-Ray Frame Buffer? Does the Save File Dialog show up and allow you to pick a place to save it?

and also one small detail. It would be nice to render dimensionings practically (i use rhino for industrial design renderings) but vfr4 does not render the dimensions unlike rhino s own render(although i assign vray materials to those dimensions). i guess this problem is about vfr.

Yes we only render surfaces - no curves or dimensions. I'll add it to our list as something to look into as I'm sure its something very useful.

[everydayobjects]

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

Displacment map crash

I have found that when I use displacement mapping on unjoined surfaces (eg. a box.) I get black lines around the surface edges. If I join the surfaces into a single (Open) polysurface and then re-render, Rhino crahes out every single time.

Best regards,
Gavin

[Micha_cg]

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

And here an exotic bug: I use a 360° jpg env texture for a groundplane and enable DOF. The focus is at the head of the frog. Bug: the frog is sharp, the groundplane blur (screenshot show the groundplane isocurves and the ground texture without DOF is perfect sharp).

[dalomar_cg]

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

Micha,

Could you send me that scene+map. I think it may be relating to the texture filtering rather than the DOF. Maybe too much blur(in the filtering, not DOF) and too much pixelation. Send it over and I'll take a look at it.

[dalomar_cg]

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

Displacment map crash

I have found that when I use displacement mapping on unjoined surfaces (eg. a box.) I get black lines around the surface edges. If I join the surfaces into a single (Open) polysurface and then re-render, Rhino crahes out every single time.

Best regards,
Gavin

The reason why you see the black edges on the unjoined object is because the displacement is acting locally on each one of the objects and there is a gap between the edges of the displaced mesh. In other words rather than displacing the mesh of the box, its displacing each of the faces of the box as an individual object. Because of this v-ray can't understand that the edges between those faces should be joined (this is what the keep continuity option does). If the object is joined, then vray will know to keep the mesh on the edges closed, which prevents those gaps. Examples are below.

As for the crash issue, I can't duplicate it. So if you can send me a scene where its happening to you and the map that your using I'll see if we can reproduce it on our end.