Camera very close to objects

2011-07-23
2013-04-25
  • David Given
    David Given
    2011-07-23

    I'm trying to render the moon. Currently I'm using Povray, modelling the terrain as isosurfaces. (See http://code.google.com/p/flooded-moon.)

    However, I'm trying to add lots of procedural detail, and while Povray has lots of really cool features, fast procedural code is not one of them -- my renders are becoming painfully slow. So I'm looking into using Renderman with Pixie instead.

    I've modelled my lunar terrain as a sphere with a displacement shader, and it all seems to work fine from a distance, but whenever I start to bring the camera too close the images all fall apart. For example:

    From a distance: http://twitpic.com/5uj8lz
    Close up: http://twitpic.com/5uj99i

    I'd really like to bring the camera down to within a few metres of the surface. Any ideas how I can make this work, or am I just trying to do things that are not feasible with Renderman?

    My RIB is:

    Display "disk1" "framebuffer" "rgb"
    Display "moon.tif" "file" "rgb"
    Projection "perspective" "fov" 40
    Option "limits" "eyesplits" 20
    Format 640 480 1

    Rotate 60  1 0 0
    Rotate 45  0 0 1
    Translate 0 0 1753
     
    WorldBegin
        TransformBegin
    Rotate 80  0 1 0
    Rotate 90  1 0 0

    Displacement "lunarsurface" "string texname"
            Sphere 1737.4 -1737.4 1737.4 360
        TransformEnd
    WorldEnd

    …and my displacement shader is:

    displacement lunarsurface(string texname = "")
    {
      float   hump = 0;
      normal  n = normalize(N);
      color c = texture(texname);
      hump = (comp(c, 0) + comp(c, 1) + comp(c, 2))/3;
     
      P = P - 50*n + n*hump*50;
      N = calculatenormal(P);
    }

     
  • Natacha
    Natacha
    2011-07-23

    Hello,

    I don't know whether this has anything to do with your problem, but in general displacement shaders are meant to affect surface rugosity, not create geometry. That means a negligible change in geometry. For example, there are implementation where displacement shaders only affect the normal vector passed to the surface shader, without affecting the computed geometry.

    Maybe the problem here is some visibility or other variable computed with the original geometry, and then the displacement being so large that it significantly changes the results.

    So in such a case my first instinct would be to embed lunar surface into the geometry, and then check whether the problem still occurs. For example a PatchMesh with well-chosen parameters might be almost as easy to use as a displacement shader (though poles might need a special handling).

    Hoping this helps,
    Natacha

     
  • David Given
    David Given
    2011-07-23

    Unfortunately using actual geometry isn't an option -- I want to model a sphere 3500000m in diameter with details on the scale on metres… and then I want to put the camera right down in the valleys. So generating the shape procedurally is my only option. I'm also going to want to use the same technique to add more features, so it's not restricted to just simple terrain.

    My Povray implementation uses an isosurface object for this, which traces the shape for which f(x, y, z)=0 for a given function. In my case, the function is looking up the gross terrain height from a massive lookup table, then procedurally adding detail based on the slope of the terrain (found from a different massive lookup table). Is there a way of doing anything like this other than using displacement shaders?

     
  • Cedric PAILLE
    Cedric PAILLE
    2011-07-26

    Hi,

    Could you put an archive of this on a server, so we can check where's the problem ?

     
  • David Given
    David Given
    2011-07-26

    I'll try and get a turnkey system up later, but for now you can get the texture from http://flooded-moon.googlecode.com/hg/KaguyaTopographyDataLowRes.png (beware: it's 20MB). It'll need converting to a TIFF. The RIB and shader source is exactly as above -- it's not a very complex model!

     
  • Natacha
    Natacha
    2011-07-26

    Hello,

    still on the geometry-instead-of-displacement idea, if that's within your reach you could try turning your isosurface into an implicit surface DSO object.

    It has been years since I last used an implicit surface, so I don't know whether it still works, but it's a very powerful features. It would basically create the geometry on demand, but without the displacement shader overhead. The only drawback is that it requires being able to code a DLL/DSO…

    I haven't been able to find the documentation in the wiki, however there is an exemple here http://www.renderpixie.com/pixiewiki/Examples/DSO_Examples

    - Natacha

     
  • Cedric PAILLE
    Cedric PAILLE
    2011-07-26

    Hi,

    try this RIB/Shader:

    RIB:

    Display "disk1" "framebuffer" "rgb"
    Display "+moon.tif" "file" "rgb"
    Projection "perspective" "fov" 40
    Option "limits" "eyesplits" 10
    Format 640 480 1
    ShadingRate .5
    Rotate 60  1 0 0
    Rotate 45  0 0 1
    Translate 0 0 1753
     
    WorldBegin
    Attribute "displacementbound" "float sphere"
    Attribute "displacementbound" "string coordinatesystem" "shader"
      TransformBegin
    Rotate 80  0 1 0
    Rotate 90  1 0 0

    Displacement "lunarsurface" "string texname"
            Sphere 1737.4 -1737.4 1737.4 360
        TransformEnd
    WorldEnd

    Shader:

    displacement lunarsurface(string texname = "")
    {
      float   hump = 0;
      normal  n = normalize(N);
      color c = texture(texname);
      hump = ((comp(c, 0) + comp(c, 1) + comp(c, 2))/3) - .5 ;
     
      P = P + (n*hump*50);
      N = calculatenormal(P);
    }

    It's slow, cause of the eye split issue, but worked for me

    Cheers.

     
  • David Given
    David Given
    2011-07-26

    That doesn't work for me -- it just spews 'Too many eye splits for primitive "(null)"' errors. If I bump the eyesplits setting up to 30,  the errors stop, but no data appears. What do your changes mean?

    Implicit surfaces look very interesting -- similar to Povray isosurfaces, but in *native code*! Would I be likely to run into the same problems with very large objects seen from very close up that I did with displacement shaders?

    Alas, the example in the link doesn't work, complaining about:

        Parameter "trace" is not declared

    …and giving me a completely black render. Setting trace to  enables raytracing, right? I gather the syntax of this has changed?

     
  • Natacha
    Natacha
    2011-07-27

    Hello,

    I think you are unlikely to run into the same problems with implicit surface than with displacements. As I said, the main difference is that in the displacement case, some of the computation is done with the undisplaced geometry, while the implicit surface creates the final geometry in the first place. However it is possible that your problem is not actually due to the mismatch between displaced geometry vs undisplaced one, and in that case the problem will obviously persist. But I still think displacements are the most likely culprit, because of the basic assumption that displacements don't change the geometry much.

    "trace" visibility attribute has indeed been deprecated. It was not directly used to enable raytracing, but rather to make an object visible to raytrace. The idea being that object potentially hit by a ray have to be kept in memory during the whole rendering time, while they can be forgotten earlier with algorithms like REYES. So mark specifically object visible to the raytracer in order to save memory.

    If I remember correctly, "trace" was deprecated in favor of finer-grained option depending which raytracer is actually used, which led to "camera", "specular", "diffuse", "photon" and "transmission" visibility attributes.

    In that example scene, the raytracer is enabled through `Hider "raytrace"` stanza, so I guess these rays count as "camera", which is 1 by default. So you should try without the `Attribute "visiliblity" …` line first, and if it doesn't show anything try with one of the visibility attributes above.

    My rendering environment is a bit messed up at the moment, so I can't craft right now a working example. However I can probably make one (in FreeBSD, while .dylib extension in the wiki example points to a Mac platform) next week-end, if you still haven't got something working by then.

    - Natacha

     
  • David Given
    David Given
    2011-07-30

    I can't make that DSO example work -- after some playing I see that the DSO *is* being called, and pixie is probing the space for an edge, but nothing ever appears. If I replace the implicit geometry with a sphere, and object is rendered, so it's not a scene issue; I've tried all the various combinations of settings I can find and it just remains blank.

    I did manage to make the menger cube example that's linked to from that page work (after I pulled it out of archive.org), but that seems to be working differently, by creating geometry explicitly rather than just describing the surface and letting Pixie do the work.

    Incidentally, is it possible to use either of these techniques with shader functions, or do I need to write a DSO to make them work? (Which, BTW, is not a problem, just more work.)

     
  • David Given
    David Given
    2011-07-30

    Oh, I forgot to add -- I notice that DSOs use floats. These only have 23 bits of mantissa, which for an object the size of my moon gives me about half a metre of precision. Is this likely to be a problem?