Corrupted rpict renderings

[andrei88k...@gmail.com]

Hello Nathaniel,

               I apologize for the long absence, I finally had time to review my past benchmarks and gather some questions concerning your Accelerad software. When using rpict with a simple scene that has small amount of geometry polygons I have experienced no problems. It’s when I render a scene with 600,000+ triangle polygons that I see a corrupted rendering that looks like its missing pixel data, as random pixels appear to be black. Also, there are some inappropriate red/green/blue edge highlights throughout the scene. Here is a link to the CPU and GPU rendering of the same .oct file.

Rpict Rendering (500x500 pixels): http://imgur.com/MA8woXf

               Do you know what can be causing these artifact? Are there any geometry limitations for Accelerad’s rpict? I tried using various rpict input args. to see if any specific one could be causing the image corruption, I also tried increasing Windows TDR to various values, up to 10 minutes with no help. I used the following input args. to generate the images above -pa 1.0 -ps 4 -pt 0.05 -pj 0.67 -pm 0.0 -pd 0.0 -dj 0.0 -ds 0.25 -dt 0.05 -dc 0.5 -dr 1 -dp 1000 -dv+ -ss 1 -st 0.15 -bv+ -av 0 0 0 -aw 0 -ab 1 -ar 0 -aa 0 -ad 512 -as 0 -i- -lr 7 -lw 0.001. For CPU execution I added the –g 0 input argument. The CPU took 27.2 sec and the GPU took 4.8 sec to generate these renderings, so there definitely is a nice speed-up to be gained by using Accelerad’s rpict.

               I’ve tried running the benchmark on a desktop with two Quadro 2000, with the hope that I can set one GPU to “Compute Only” mode using the NVIDIA SMU utility, but for some reason the Quadro didn’t support this mode. I have a desktop with two GTX 980s that I would like to use for my next benchmark. Is it possible to dedicate an entire GPU to only Accelerad execution? Have you used NVIDIA SMI utility to configure GPUs for Acccelerad execution?

               I’m curios of the future of this project and how many people are working on it. Do you plan on continuing development of this project in the future as new Radiance versions are released? I work with the Graphics Research & Analysis Facility (GRAF) at the NASA Johnson Space Center. We use Radiance as part of our lighting software analysis tool set and we are greatly interested in speeding up our renderings such as using Acccelerad.

 

Thank you for your time,

Andrei Kolomenski

 

 

[Nathaniel Jones]

Hi Andrei,

These are some interesting artifacts you're seeing. I was able to render a model with 600,000 triangles and the settings you listed without any problems on a Quadro K4000. Since you're getting an image result, TDR isn't a problem. Here are a few ideas for debugging the issue.

• First, make sure you're using the latest version of Accelerad, which is version 0.2 beta and is equivalent to Radiance version 4.3.a.2. Also, check for updates to your graphics drivers.

• Do you see any error messages on the console? Running with aa > 0 could help; in the current version, the ambient calculation's error messages are somewhat clearer than the other rpict error messages.

• Does Accelerad work for smaller triangle-count models with the same materials and settings? Accelerad uses 64-bit addressing, so it can handle very large collections of geometry, but its possible that your Quadro 2000 might run out of space when you have many triangles. Still, my 600,000 triangle model only allocates about 0.1 GB on the GPU. Do the artifacts go away if you render on your GTX 980?

• What are the units of your model? Accelerad uses single-precision float arithmetic for ray tracing, so it can sometime have issues with rays that are very far from the origin. I've done some work to correct this, but if your model is scaled in millimeters, scaling it to meters may help.

• Do you have any materials with high specularity or roughness parameters? The last Accelerad release fixed an issue in which specular surfaces caused similar black pixels. This could be a similar issue. Setting these material parameters to zero could help to diagnose it.

• If none of these work, are you able to share your octree file? Reproducing this error will help to solve it.
  

NVIDIA SMI doesn't support cards prior to 2011, so your Quadro 2000 may not be able to change modes. It has limited feature support for GTX cards, so it's hard to say if it will work with you GTX 980s. You could also try using the CUDA_VISIBLE_DEVICES environment variable to keep the compute work on a device that is not attached to a monitor. This would prevent Accelerad from using some GPUs, but keeping other processes off of Accelerad's GPU is still up to the operating system.

Releases of Accelerad generally keep up with new Radiance and OptiX versions, though usually with some lag time. Also like Radiance and OptiX, there is no fixed schedule for releases.

Nathaniel

[andrei88k...@gmail.com]

Hi Nathaniel,

 

            Thanks for the response and the multiple suggestions. I considered each of your suggestions and included my response in-line with your comments.

 

            I tested accelerad rpict with a modified octree of the same scene that was causing the previous visual artifacts. The octree was simplified to only include triangle surfaces and plastic/metal materials, and exclude texture mods using texfunc (tmesh,cal). This time accelerad rpict rendered correctly on every system. I’m not sure of the exact difference between the octrees beyond what I previously mentioned as I didn’t generate the one supplied to me, but I can take a closer look at them if needed.

 

            So I moved on to a bigger model (ISS exterior) and I encountered run-time errors with native Radiance rpict and Accelerad rpict. I was surprised to see problems with Radiance rpict on Windows 7 64bit OS. I suspect these problems were caused by the large model geometry (2.4 GB .rad file with 11 million polygons). The same model rendered correctly on a 64 bit Linux system. I posted about this issue on the Radiance general forum: http://www.radiance-online.org/pipermail/radiance-general/2015-April/010863.html

 

Do you know of any model size constraints in terms of polygons or vertices in Radiance?

 

• First, make sure you're using the latest version of Accelerad, which is version 0.2 beta and is equivalent to Radiance version 4.3.a.2. Also, check for updates to your graphics drivers.

I confirmed that I’m running Accelerad version 0.2 beta with Radiance 4.3.a.2. I did notice my Radiance version is 32 bit. I’m yet to test Accelerad with a 64 bit build of Radiance. Are you using a 32 or 64 bit Radiance version?

• Do you see any error messages on the console? Running with aa > 0 could help; in the current version, the ambient calculation's error messages are somewhat clearer than the other rpict error messages.

I included the “-e error_log.txt” input argument to rpict to save the error messages to a text file. It didn’t contain anything important. Here is what I saw:

*** PID  7992: rpict -vtv -vp -139.699994 -27.940032 0.000000 -vd 0.984808 0.173649 0.000000 -vu 0.173649 -0.984808 -0.000000 -vh 45.948718 -vv 35.000000 -x 400 -y 400 -av 1 1 1 -e error_log.txt scene_frozen.oct

• Does Accelerad work for smaller triangle-count models with the same materials and settings? Accelerad uses 64-bit addressing, so it can handle very large collections of geometry, but its possible that your Quadro 2000 might run out of space when you have many triangles. Still, my 600,000 triangle model only allocates about 0.1 GB on the GPU. Do the artifacts go away if you render on your GTX 980?

No, rendering on a GTX 980 didn’t remove the artifacts (for original octree of ISS lab interior). Yes Acceleard works for small geometries and simple materials. I’ve tested with smaller models and obtained correct renderings.

• What are the units of your model? Accelerad uses single-precision float arithmetic for ray tracing, so it can sometime have issues with rays that are very far from the origin. I've done some work to correct this, but if your model is scaled in millimeters, scaling it to meters may help.

Scale is in meters and no single dimension is greater in magnitude. Using the getbbox command on the model geometry I see.

     xmin      xmax      ymin      ymax      zmin      zmax

 -20.2822   45.0061  -36.1178   35.4449  -50.2798   51.1047

• Do you have any materials with high specularity or roughness parameters? The last Accelerad release fixed an issue in which specular surfaces caused similar black pixels. This could be a similar issue. Setting these material parameters to zero could help to diagnose it.

I checked the specularity and roughness of each material used and noticed that indeed some of these parameters were set quite high. What is considered a high specularity and roughness value?

I see specularity values as high as 0.935 and roughness values as 0.36. Can these be causing issues? What’s strange is that the same materials were used in the creating the new octree of the ISS lab that did render properly with Accelerad. So I think my artifacts were caused by something else.

• If none of these work, are you able to share your octree file? Reproducing this error will help to solve it.

Sorry I can’t share the files; they are proprietary and subject to export control. Please let me know if you would like me to look up something inside the .rad or octree files, I will be glad to do so for you.

 

NVIDIA SMI doesn't support cards prior to 2011, so your Quadro 2000 may not be able to change modes. It has limited feature support for GTX cards, so it's hard to say if it will work with you GTX 980s. You could also try using the CUDA_VISIBLE_DEVICES environment variable to keep the compute work on a device that is not attached to a monitor. This would prevent Accelerad from using some GPUs, but keeping other processes off of Accelerad's GPU is still up to the operating system.

 

 

Thank you for suggesting using CUDA_VISIBLE_DEVICES environment variable, I wasn’t aware that it can be used to control GPU selection by CUDA applications.

 

 

My work team wants to invest in the Tesla M2090 GPU for current use of Accelerad and future development. Is this is an optimal card for running Accelerad or would you refer us to a different one?

 http://www.bhphotovideo.com/c/product/1001374-REG/nvidia_900_21030_0040_100_tesla_gpu_m2090_6gb.html

 

 

Currently, my main concern is to be able to use (native) rpict and oconv for large geometries and insure this works correctly in Windows 7 64 bit as it does in Linux 64 bit. This is addressed in the Radiance general forum (link at top of this response). Next, I want to try the same large geometries with Accelerad rpict, once it’s working with native rpict.

 

 

Thank you for the input,

Andrei Kolomenski

[Nathaniel Jones]

Hi Andrei,

This points to there being a problem with Accelerad's interpretation of the tmesh.cal file, which is used to vary surface normals in order to create the appearance of out-of-plane curvature. tmesh.cal can also be used to provide image uv-coordinates, but that is not yet implemented in Accelerad.

Try running the simulation with -ab 0 and -lr 0. That way, you'll only see directly bounced lighting. If there's a polygon in the field of view with corrupted surface normals, it should hopefully be easy to pick out. Would it be possible to see the .rad file definition for that polygon and its texfunc?

I agree that your specular and roughness settings are probably ok. The first Acclerad versions had problems when a material's specularity was higher than the -st setting. Setting -st 1 used to be the way to prevent that.

Accelerad's executables are 64-bit, so any errors you encounter with 64-bit compiled Radiance on Windows OS are likely to also occur in Accelerad. I pull updates from Greg Ward frequently, so bug fixes in the standard Radiance distribution will be mirrored in the next Accelerad version.

For investing in new GPUs for compute-intensive applications like Accelerad, the main considerations are memory size number of CUDA cores. Processor architecture is also useful to know, since newer generation generally tend to outperform previous ones. The card that you shared uses Fermi architecture, which is the oldest architecture that Nvidia and Accelerad still support. Its specs are probably good enough to give you some speedup, but its age makes it a riskier investment, in my opinion. Most of the testing for Accelerad is done on a Tesla K40, which has twice the memory and 5 times the number of cores. While Accelerad is able to use cores from multiple GPUs to scale up, it does still need to copy the entire model into the memory of each GPU and allocate scratch space there as well, so there is some penalty incurred by running on two smaller GPUs as opposed to one larger GPU with the same combined number of cores.

Nathaniel

[andrei88k...@gmail.com]

Hi Nathaniel,

 

Thank you for the informative post as always! Below I pasted two texture & polygon definitions from my original geometry (ISS Interior), which is causing the visual artifacts. Also, I pasted the contents of tmesh.cal, I don’t think this file was modified from the original Radiance 2.x release. I believe it is an old .cal from a previous Radiance 2.x release. This tmesh.cal file is probably what’s causing the problem.

 

I tried using –ab 0 –lr 0 input args with no luck, I still saw the red/green/blue line outlining the edges and the random black pixels of what appears to be missing rendering data. Let me know if you would like me to run another configuration.

 

Thank you for the input on the post (http://www.radiance-online.org/pipermail/radiance-dev/2015-April/thread.html) about running oconv & rpict with large geometry. “long long hval” in objset.c fixed my run-time crashes.

 

Can you please rebuild rpict & rtrace with the fixed objset.c? This way I can test Accelerad with the large geometry file and I can report on the results.

 

So the M2090 is a bit dated and certainly not the best choice for purchasing a GPGPU. Since Accelerad uses single precision arithmetic I think the GTX 980 is great candidate for the “best bang for your buck” GPU. I will perform more detailed benchmarks with it in the near future, especially once I can run the large model.

 

Cheers,

Andrei Kolomenski

 

 

**********************************************************

NONE texfunc M-nor

4 dx dy dz tmesh.cal

0

10           1

    0.00000000     0.00000000    -0.24034305

    0.00000000     0.00000000     0.97068791

    0.00000000     0.00000000    -0.00044458

 

M-nor polygon LAB_ACBM_FWD_46_0.OBJ.6

0

0

9

        691.188904          34.966642          -9.406005

        691.017883          34.966217          -9.406853

        691.016907          34.966287          -9.248815

 

NONE texfunc M-nor

4 dx dy dz tmesh.cal

0

10           0

    0.00002429     0.00050837    -0.99598868

   -0.00211461    -0.02237322    -0.14057944

   -0.00307692    -0.06936024    -0.55842358

 

M-nor polygon LAB_ACBM_FWD_46_0.OBJ.8

0

0

9

        690.980896          34.910709          -9.462362

        690.978882          35.958855          -9.589429

        690.981873          34.852939           -9.53979

 

**********************************************************

*** tmesh.cal

{

               Interpolate triangle-mesh values using barycentric coordinates.

 

               A1                         = Major axis (0==X, 1==Y, 2==Z)

               A2 through A10  = Surface normal perturbation matrix

or:

               A2 through A7    = Lookup in 2-dimensional pattern or texture

}

                                                                           { Get dominant coordinates }

bu = select(arg(1)+1, Py, Pz, Px);

bv = select(arg(1)+1, Pz, Px, Py);

                                                                           { Compute variables }

v1 = bu*arg( 2) + bv*arg( 3) + arg( 4);

v2 = bu*arg( 5) + bv*arg( 6) + arg( 7);

v3 = bu*arg( 8) + bv*arg( 9) + arg(10);

                                                                           { Surface normal perturbation }

nf = 1/sqrt(v1*v1 + v2*v2 + v3*v3);

dx = v1*nf - Nx;

dy = v2*nf - Ny;

dz = v3*nf - Nz;

                                                                           { Tiled texture coordinates }

u = frac(v1);

v = frac(v2);

 

**********************************************************

[Nathaniel Jones]

Hi Andrei,

I rendered the two triangles that you sent in Accelerad with your settings, and they worked fine. It's possible that other triangles may still be causing problems, but if you see the same artifacts in the same places with -lr 0 -ab 0, then this seems less likely (unless perhaps you have a texfunc modifying a light source in the model?). In your simplified model, did you remove anything other than the texfuncs? Unfortunately, the next debugging step might be to look for specific triangles that are causing issues, but this could be prohibitively difficult if you have a large number of texfuncs in your model.

Do the artifacts appear exactly the same each time you run it, or are they random from one run to the next? If you move the camera, do they appear to be in the same places on the geometry, or are they stationary relative to the camera? If you hover over the pixels to get their values in wxfalsecolor, are the colored pixels' rgb values near unity, or much larger?

Your tmesh.cal from Radiance 2.x appears to be the same as the current version. I'm merging Greg's objset.c patches to Accelerad. They will be part of the next release, which should come out pretty soon once I've handled a few lingering issues. If you want to check that Greg's changes work, you can pull the current head from the Radiance CVS, or wait for it to be reflected in NREL's GitHub version. The current head should now run on Windows.

Nathaniel

[andrei88k...@gmail.com]

Hi Nathaniel,

I’m excited to see that Accelerad 0.3 beta is released; I just registered to download it. I see that this Accelerad release includes Radiance updates up to version 5.0.a. Since 5.0.a.3 (https://github.com/NREL/Radiance/releases) includes 64-bit long support for Windows, I’m assuming Accelerad 0.3 does not have the 64-bit long support, or is this fix implemented in Accelerad 0.3? Either way, I’m curious to render a bigger model and the one that has caused the previous artifacts.

I’ve finally had time to look into some of your previous remarks concerning the artifacts. My comments below address your previous points.

 

Cheers,

Andrei Kolomenski

 

·       The light sources used for this scene consist of 12 quadrilateral “polygon” primitives each applied to a “light” primitive, texfunc does not modify the light sources.

 

·       Removing texfunc from being applied to the polygon geometry primitives does remove the artifacts. I’ve talked to my co-worker that gave me the new, artifact free, geometry .rad file and he said he used “obj2rad” to generate it.

 

·       Looking at the radiance values for the artifacts showed that one of the RGB channels was oversaturated, for example green artifact edge pixel has the following radiance values: red=0.0180664, green=37.25, blue=0.0184326. Here is a link to a 24 bit RGB normalized image with the artifacts: http://imgur.com/G7tDu3O (The top & left corners have a grey line because I used printscreen, they are not artifacts J)

 

·       The artifacts are reproducible from two different Windows desktops. Using default rpict input args., I performed an image difference between various renderings and I obtain a completely black image with zero radiance for each pixel and RGB channel.

 

·       The artifacts always appeared at the same position as I moved -vp parameter. The artifacts looked like they concentrated along surface edges, their position didn’t change when changing –vp, however they did appear to have slightly different RGB components.

 

·       Yes, you are correct, tmesh.cal is the same as it appears in the new Radiance release. I forgot that my co-worker replaced the original tmesh.cal (2.x) with the one found in Radiance 4.3.a. So the artifacts are present with the new tmesh.cal file using Artifacts are present for Radiance 4.3a, Accelerad 0.2 beta.

[Nathaniel Jones]

Hi Andrei,

Version 0.3 includes all changes to the main Radiance branch up to May 2. This includes support for Windows 64-bit long longs in objset.c, so your large models should load the same way they do in the current Radiance head release.

Your observations seem to eliminate the possibility of a memory leak from outside the program and also don't point to any of the per-pixel errors that were reported by version 0.2. I would suggest running the same test with version 0.3, which has much better error reporting. Be sure your settings do not include the -w option, as this turns warnings off.

Nathaniel

[andrei88k...@gmail.com]

Hi Nathaniel,

I tried out the Accelerad 0.3 with Radiance 5.0.a.3 on Windows 7 64bit. It does render big exterior models that previously crashed due to the absence of the “long long” fix in objset.c. Thank you for incorporating this fix into Accelerad!

Unfortunately, I still see the artifacts exactly at the same locations using the same rpict input args. as before; an image subtraction of the artifact images from Accelerad 0.2 & 0.3 yielded a completely black image with a maximum of zero radiance across all channels. So I’m not sure what’s causing these artifacts, I wish I could help locate the problem, but I truly don’t know other than the fact that removing the texfunc primitive that uses tmesh.cal does remove the artifacts.

Another new issue I found is that some bad polygons that have “zero area” cause Accelerad rpict to crash; whereas rpict doesn't crash but simply doesn't render these polygons. I have a large exterior model that has many polygons with “zero area”, some of these do not cause the program to crash but some specific ones do. I isolated one of these & tried running Accelerad with it. This is the warning output I saw:

accelerad_rpict: warning - zero area for polygon "H_UMB_BRKT_3.OBJ.711"

accelerad_rpict: internal - triangulation failed for polygon "H_UMB_BRKT_3.OBJ.711"

 

               Polygon definition:

 

LINER polygon H_UMB_BRKT_3.OBJ.711

0

0

9

               0.524853             -1.970085            -2.93939

               0.520652             -1.965289            -2.939364

               0.524853             -1.970085            -2.93939

 

So this is a bad polygon that really shouldn't be included in the model, but it does cause GPU execution of Accelerad to crash whereas passing the “-g 0” parameter doesn’t crash but simply produces a completely empty image. Is there a way to ignore these “zero area” polygons in the GPU execution of Accelerad? A fix on my side would be to insure that no "zero area" polygons are defined in the model geometry.

 

Best Regards,

Andrei Kolomenski

[Nathaniel Jones]

Hi Andrei,

It's too bad none of the new warnings tripped in the new version. I was hoping this could identify the source of the bug, but at least it eliminates some more possibilities. I've been tying out a few things on my end related to extreme corner cases with texfuncs. This is leading to a couple improvements for the next version, but so far I've been unable to reproduce the saturated pixels that you're experiencing. Because the artifacts tend to be clustered along edges, I'm wondering if someone might have modeled tiny rounded edges in your model rather than just two big polygons coming together at an angle.

Do all of the materials in the model have zero specularity and roughness (the 4th and 5th numerical arguments for the material objects)? If not, it's also possible that one of these is interacting with the surface normals created by the texfunc in an odd way. Setting -ss to 0 or setting -st to 0 or 1 might help to identify the method that causes the problem if one of these options makes the artifacts go away.

My last suggestion is to try to generate a minimal model that reproduces the error and which you are able to share. Unfortunately, without being able to reproduce the error over here, there's not much I can do to debug it.

I've downgraded the "triangulation failed" error to a warning for the next release. This will cause Accelerad to skip over degenerate triangles in the next release rather than abort. It seems like if the degenerate triangles are being generated by obj2rad, then there's not much point in asking the user to clean them up.

Nathaniel

[andrei88k...@gmail.com]

Hi Nathaniel,

I re-read the Accelerad Readme and noticed that there may be issues with when the viewpoint of the rendering is more than 100 units from the geometry. I think this is the main reason for the observed artifacts. The original geometry of the artifact scene was exported in inches and never converted back to meters. Due to this an input arg, -vp 677.54495 -10.99839 0.0, is used to produce the artifact scene. I scaled down the scene by factor of 100 (!xform –s 0.01) and the artifacts disappeared using -vp 6.7754495 -.1099839 0.0. So all along it was the scale of the model, which was problematic for single precision computations on the GPU.

Now, on to the big ISS model (2.4 GB .rad geometry file) that had the “triangulation failed” error. I modified obj2rad.c to exclude degenerate polygons from the output .rad file. I ran accelerad_rpict with no errors however the final rendering turned out to be completely black. I pasted the log output of accclerad_rpict for the big ISS model below for your reference. I’m not sure what’s going wrong this time; but I feel like the large size of the model is at the root of the problem. I do know that an abridged version (1 GB .rad geometry file) does render correctly on the GPU. I monitored GPU usage using NVIDIA-SMI utility using the following command:

            nvidia-smi -q -d ECC,UTILIZATION,COMPUTE,PIDS,MEMORY,POWER -i 1 -l 2 -f GPU_log.txt

Also, it is important to note that I designate a TCC compute mode GPU for accelerad execution using the “CUDA_VISIBLE_DEVICES” env. variable. I was surprised to see that the GPU memory was only taxed 16-17 MBs through-out the entire run; and the GPU utilization was at 0% the entire run..

  Utilization

        Gpu                                : 0 %

        Memory                      : 0 %

    Compute Processes

        Process ID                  : 8628

            Name                    : C:\Program Files\Accelerad\bin\accelerad_rpict.exe

            Used GPU Memory         : 17 MiB

 

Also, I monitored CPU RAM between CPU (-g 0) & GPU execution and found out that GPU version uses more CPU RAM than the CPU version, which appeared strange to me. The CPU version used 3.6 GBs at peak and the GPU version used 4.3 GBs at peak. I monitored the same stats for Interior & Small Exterior renderings that produced correct results and the same pattern was observed.

So my main questions are:

            Is there any size limitation on the geometry .rad files in Accelerad?

            What is the largest geometry .rad file successfully tested with Accelerad?

            Why is GPU RAM & Utilization (as monitored by NVIDIA SMI) minimal during Accelerad GPU execution?

            Do you have a preferred way of designating & monitoring a GPU used by Accelerad?

Thank you for the support,

Andrei Kolomenski

**************

*** PID  6704: accelerad_rpict -vtv -vp -89.699994 -27.940032 0.000000 -vd 0.984808 0.173649 0.000000 -vu 0.173649 -0.984808 -0.000000 -vh 45.948718 -vv 35.000000 -x 512 -y 512 -e C:\Users\akolomen\Desktop\Radiance_GPU_Benchmark\rpict\Exterior_Corrected\Images\Bench1_Log.txt scene_light.oct

 

OptiX 3080 found 1 GPU device:

Device 0: Quadro 2000 with 4 multiprocessors, 1024 threads per block, 1251000 kHz, 1073414144 bytes global memory, 128 hardware textures, compute capability 2.1, timeout disabled, Tesla compute cluster driver enabled, cuda device 0.

 

accelerad_rpict: warning - Unsupported object:

void(-1) mirror(33) RAD_MIRROR

0

3 0.8 0.8 0.8

 

accelerad_rpict: warning - Unsupported object:

void(-1) texfunc(3) wrinkled

10 xwrink ywrink zwrink wrinkle.cal -rx 30 -ry 30 -rz 30

3 0.05 0.5 0.1

 

accelerad_rpict: warning - Unsupported object:

void(-1) texfunc(3) retro-normal

4 -Dx-Nx -Dy-Ny -Dz-Nz .

0

 

accelerad_rpict: warning - Unsupported object:

void(-1) metdata(38) RETRO3M3990

5 retro_refl 3M3990.dat reflector.cal retro_theta retro_phi

5 0.47 0.47 0.47 0.2586 0.03

 

accelerad_rpict: warning - Unsupported object:

void(-1) metdata(38) RETROSCOTCHLITE

5 retro_refl 3M3990.dat reflector.cal retro_theta retro_phi

5 0.63 0.63 0.63 0.0872 0.03

 

accelerad_rpict: warning - zero area for polygon "S0_CL_SHROUDS_FACE_73.OBJ.443"

accelerad_rpict: warning - zero area for polygon "S0_CL_SHROUDS_FACE_73.OBJ.883"

accelerad_rpict: warning - zero area for polygon "S0_CL_SHROUDS_FACE_73.OBJ.900"

accelerad_rpict: warning - zero area for polygon "S0_CL_SHROUDS_FACE_73.OBJ.906"

accelerad_rpict: warning - zero area for polygon "S0_CL_SHROUDS_FACE_73.OBJ.918"

accelerad_rpict: warning - zero area for polygon "S0_CL_SHROUDS_FACE_73.OBJ.986"

accelerad_rpict: warning - zero area for polygon "S0_CL_SHROUDS_FACE5.OBJ.3205"

accelerad_rpict: warning - zero area for polygon "S0_CL_SHROUDS_FACE5.OBJ.3389"

accelerad_rpict: warning - zero area for polygon "S0_302_SPDA_DOOR_41.OBJ.1028"

accelerad_rpict: warning - zero area for polygon "S0_PWP_GF_2.OBJ.642"

accelerad_rpict: warning - zero area for polygon "S0_PWP_GF_2.OBJ.1716"

accelerad_rpict: warning - zero area for polygon "S0_PWP_GF_2.OBJ.2199"

accelerad_rpict: warning - zero area for polygon "S0_GPS_ANT_58.OBJ.58"

accelerad_rpict: warning - zero area for polygon "S0_GPS_ANT_58.OBJ.326"

accelerad_rpict: warning - zero area for polygon "S0_GPS_ANT_58.OBJ.365"

accelerad_rpict: warning - zero area for polygon "S0_GPS_ANT_58.OBJ.593"

accelerad_rpict: warning - zero area for polygon "S0_GPS_ANT_58.OBJ.838"

accelerad_rpict: warning - zero area for polygon "S0_GPS_ANT_58.OBJ.867"

accelerad_rpict: warning - zero area for polygon "S0_GPS_ANT_58.OBJ.906"

accelerad_rpict: warning - zero area for polygon "S0_302_REEL_113.OBJ.370"

accelerad_rpict: warning - zero area for polygon "S0_PWP_LMTR_WIF_10.OBJ.684"

accelerad_rpict: warning - zero area for polygon "S0_PWP_LMTR_WIF_10.OBJ.795"

accelerad_rpict: warning - zero area for polygon "S0_CL_SHROUDS_FAC_200.OBJ.789"

accelerad_rpict: warning - zero area for polygon "S0_CL_SHROUDS_FAC_200.OBJ.1765"

accelerad_rpict: warning - zero area for polygon "S0_CL_SHROUDS_FAC_200.OBJ.2931"

accelerad_rpict: warning - zero area for polygon "S0_CL_SHROUDS_FAC_200.OBJ.3087"

accelerad_rpict: warning - zero area for polygon "S0_CL_SHROUDS_FAC_200.OBJ.3246"

accelerad_rpict: warning - zero area for polygon "S0_CL_SHROUDS_FAC_200.OBJ.3708"

accelerad_rpict: warning - zero area for polygon "S0_CL_SHROUDS_FAC_200.OBJ.4617"

accelerad_rpict: warning - zero area for polygon "S0_CL_SHROUDS_FAC_200.OBJ.4824"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_S_UP_76.OBJ.1785"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_S_UP_76.OBJ.3281"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_S_UP_76.OBJ.3329"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_S_UP_76.OBJ.3482"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_S_UP_76.OBJ.4815"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_S_UP_76.OBJ.4816"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_S_UP_76.OBJ.4828"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_S_UP_76.OBJ.4830"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_S_UP_76.OBJ.4833"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_S_UP_76.OBJ.5014"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_S_UP_76.OBJ.5015"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_S_UP_76.OBJ.5017"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_S_UP_76.OBJ.5018"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_S_UP_76.OBJ.5024"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_S_UP_76.OBJ.5025"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_S_UP_76.OBJ.5027"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_S_UP_76.OBJ.5057"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_S_UP_76.OBJ.5059"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_S_UP_76.OBJ.5061"

accelerad_rpict: warning - zero area for polygon "S0_SPR_DEP.OBJ.1286"

accelerad_rpict: warning - zero area for polygon "S0_CL_SHROUDS_FACE2.OBJ.455"

accelerad_rpict: warning - zero area for polygon "S0_CL_SHROUDS_FACE2.OBJ.470"

accelerad_rpict: warning - zero area for polygon "S0_CL_SHROUDS_FACE2.OBJ.1949"

accelerad_rpict: warning - zero area for polygon "S0_PWP_TL_STNCH_4.OBJ.710"

accelerad_rpict: warning - zero area for polygon "S0_PWP_FT_RSTRT_3.OBJ.1643"

accelerad_rpict: warning - zero area for polygon "S0_CL_SHROUDS_FAC_190.OBJ.270"

accelerad_rpict: warning - zero area for polygon "S0_CL_SHROUDS_FAC_190.OBJ.785"

accelerad_rpict: warning - zero area for polygon "S0_CL_SHROUDS_FAC_190.OBJ.952"

accelerad_rpict: warning - zero area for polygon "S0_CL_SHROUDS_FAC_190.OBJ.1194"

accelerad_rpict: warning - zero area for polygon "S0_CL_SHROUDS_FAC_190.OBJ.1603"

accelerad_rpict: warning - zero area for polygon "LCA_MTSAS_2_1.OBJ.4075"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_P_UP_75.OBJ.11"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_P_UP_75.OBJ.12"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_P_UP_75.OBJ.21"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_P_UP_75.OBJ.262"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_P_UP_75.OBJ.932"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_P_UP_75.OBJ.1378"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_P_UP_75.OBJ.1386"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_P_UP_75.OBJ.1387"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_P_UP_75.OBJ.1862"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_P_UP_75.OBJ.1864"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_P_UP_75.OBJ.1866"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_P_UP_75.OBJ.1867"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_P_UP_75.OBJ.2328"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_P_UP_75.OBJ.2329"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_P_UP_75.OBJ.2332"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_P_UP_75.OBJ.2333"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_P_UP_75.OBJ.2563"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_P_UP_75.OBJ.2612"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_P_UP_75.OBJ.2739"

accelerad_rpict: warning - zero area for polygon "S0_302_MTS_P_UP_75.OBJ.3311"

accelerad_rpict: warning - zero area for polygon "S0_302_CPDS_BOOM_206.OBJ.363"

accelerad_rpict: warning - zero area for polygon "S0_302_CPDS_BOOM_206.OBJ.402"

accelerad_rpict: warning - zero area for polygon "S0_302_CPDS_BOOM_206.OBJ.768"

accelerad_rpict: warning - zero area for polygon "S0_302_CPDS_BOOM_206.OBJ.811"

accelerad_rpict: warning - zero area for polygon "S0_302_CPDS_BOOM_206.OBJ.1981"

accelerad_rpict: warning - zero area for polygon "S0_302_CPDS_BOOM_206.OBJ.2397"

accelerad_rpict: warning - zero area for polygon "S0_302_CPDS_BOOM_206.OBJ.2402"

Geometry build time: 195997 milliseconds.

OptiX compile time: 449 milliseconds.

OptiX kernel time: 85497 milliseconds (85 seconds).

accelerad_rpict: ray tracing time: 282783 milliseconds (283 seconds).

[Nathaniel Jones]

Hi Andrei,

Now the artifacts start to make sense! The adjustments I made for large coordinates used the vertex normals instead of the polygon normals. These are only different when a texfunc is used, which is why the artifacts never came up before. I can switch over to using polygon normals and hopefully have the bug fixed in the next release.

The number of objects in a Radiance octree is stored in an int32, so technically a .rad file can contain up to 2,147,483,647 objects. OptiX has an additional limitation that caps the size of GPU buffers at UINT_MAX, so the number of vertices or triangles cannot exceed 4,294,967,295. If you go over this amount, you could get rollover without seeing an error. For the next release, I'll pass array lengths to OptiX as int64, which should prompt an error from OptiX instead of no error for this case. However, it doesn't look like your Quadro 2000 has enough memory for something that size anyway. Do you get the same issue on the GTX 980?

The GPU utilization that you show looks suspect. I use nsight for GPU process monitoring. You can run it out of Visual Studio or Eclipse, and it will plot memory usage and show you when each GPU kernel runs. CUDA_VISIBLE_DEVICES is the best way to control which GPUs are used.

As far as your RAM usage, keep in mind that both the CPU and GPU have access to the RAM, and they use it among other things to pass information between them. So it's not surprising the the RAM usage goes up when the GPU is used.

Hope this helps,

Nathaniel