Optix 7.6

[Frida Kosofsky]

OptiXPrime is an older ray-casting only API, and it does not make use of the RTX hardware. OptiX 7.2 is the current version of OptiX that makes full use of the RTX hardware acceleration features and supports multi-level instancing, motion blur, and programmable shading. OptiX does not have a CPU fallback, you would need to implement a CPU renderer separately.

Yes, you could use OptiX for this kind of radio simulation easily. There are other OptiX users doing simulations very similar to what you describe. I think you could demonstrate the feasibility of this by using or making minor modifications to the samples we provide with the OptiX SDK.

No, sorry, OptiX Prime is not a CPU fallback. OptiX Prime runs only on the GPU, but it does not take advantage of the RTX hardware acceleration on newer GPUs. OptiX 7 also use the GPU, and it additionally makes use of the RTX hardware units. If you are starting a new project using OptiX, we recommend starting with the lastest version of OptiX, which is currently OptiX 7.2.

Yes, in versions before OptiX 7.0.0.

Use the OptiX SDK 6.5.0 which is the most recent SDK release with both the older OptiX ray-casting API and OptiX Prime ray-intersection API.

Documentation for all of these is available online here: -docs.nvidia.com/

Both SDKs also contain an optixRaycasting example which shows how to do ray-triangle intersection testing only with the full OptiX API, which would use the RTX hardware and allow much more flexibility than the old OptiX Prime API, though GPU-only then.

See here: -error-failed-to-load-optix-library/70671/53

Also it could be that there are issues with OptiX Prime on recent Linux drivers according to that thread, which is to be investigated internally.

On the host side you need to include the nvrtc.h header (inside your CUDA//include folder) and link against the CUDA export library named nvrtc.lib (inside the CUDA//x64/lib folder to be able to compile your application doing nvrtc API calls.

That export library only contains the interface of the dynamic link libraries which implement the actual NVRTC compiler and a precompiled standard library it needs.

These are located inside the CUDA//bin folder and are named with an nvrtc-prefix and the CUDA version, e.g. for Windows CUDA 10.1 they are named nvrtc64_101_0.dll and nvrtc-builtins64_101.dll.

These need to be redistributed along with the application.

Since NVRTC can only compile device code, care needs to be taken to never include any host compiler includes inadvertently (also described inside the linked threads), because you cannot expect a target system to have any compiler installed, at least under Windows.

If you do not have any need to generate CUDA device code at runtime, there is also no need to use NVRTC at all.

You should simply build everything with NVCC and ship the translated PTX code with your application.

Ok I think I got OptiX to compile and work with a Cuda application. My question now is can the ray parameter struct, Params, in the SDK, be templated? If so, how would that change the compilation process?

You want the structure which is used as launch parameter block in constant CUDA memory to be a template?

Why? Based on what template arguments?

How many different launch parameter structures would you need and how would that change the device programs accessing that data?

Usually you would implement a specific launch parameter structure which exactly matches to how the device programs inside one or multiple pipelines are coded. That is something you hardcode once and never touch again.

Note that the constant CUDA memory the launch parameters reside in is limited to 64 kB. Means whatever big data you need to access globally, only store a pointer to that inside the launch parameters.

Make the launch parameter structure as small as possible. Place fields in them according to their alignment requirements (in decreasing alignment) to prevent the compiler from adding unnecessary padding.

No. None of the available ray tracing APIs (OptiX, DXR, Vulkan Raytracing) support double precision data in acceleration structures, the ray definition, the transforms, or any other built-in functionality. That is all 32-bit floating point precision.

Note that double precision performance on standard desktop and mobile GPUs is dramatically slower than floating point performance except for some compute-only products which in turn have no hardware RT cores. (Your V100 is one of them.)

You can query the single to double precision performance ratio via the CUDA runtime API cudaGetDeviceProperties() or CUDA driver API cuDeviceGetAttribute() calls.

The forum has a search feature in the top right which can be limited to sub-forums when starting the search, for example, on the OptiX forum view. Please have a look into these previous discussions about that topic which explain some options. Look out for comments on watertight intersections in the results as well.

=double%20precision%20%23visualization%3Aoptix

the reason im asking for double precision is because i only want to do 2d graphics, polygonal objects, but from what i understand, in optix, the way to represent polygons are piecewise linear curves, with thickness.

The curve primitives in OptiX are not 2D. They are round 3D shapes, like cylinders or the volume built by sweeping a sphere with varying radius along a 3D curve. Their main use case is the implementation of hair strands in 3D renderers.

A lot of care has been taken to make the curve intersection algorithms as precise as possible, but depending on your scene and camera setup there could of course be precision issues from the finite floating point representation.

But ray tracing is not working like rasterization where line primitives will affect whole pixels depending on specific rasterization rules (like diamond exit) to either set or not set a pixel on the screen.

Note that curve primitives can be a lot thinner than one pixel depending on the camera setup. Means if the sampling of the fragments making up one pixel on the screen is not dense enough, you will simply not be able to hit the curve with all rays because the curve can fall between the discrete fragment sample points. That is unrelated to floating point vs. double precision. (Nyquist theorem comes to mind.)

That is why curves are usually rendered by partitioning each pixel into very many fragments which each define a primary ray to accumulate the hit and miss results from geometric primitives accurately. The OptiX SDK curve examples show that.

Are you saying you want to shoot rays in the same plane as the geometry?

Otherwise the z-component of neither the ray origin nor the ray direction should be zero if you plan to project the polygon outlines onto some camera plane.

I think a rasterizer could handle that a lot faster and would also allow overlapping geometry by render order without the need to handle depth separation (painter algorithm). Precision could be increased by using multisampling.

Maybe have a look at the NVIDIA Path Rendering SDK instead which uses a dedicated OpenGL extension GL_NV_path_rendering to implement hardware accelerated resolution independent vector graphics.

-path-rendering

-accelerated-path-rendering

Does that make sense? Set the Z coordinates of your ray origin & direction to zero. Do not set the Z coordinates of your polygons to zero. Do the opposite and use only vertical quads make out of triangles.

I have been having the same issue now and then. I think I noticed it the first time in Blender 2.92.

It is not necessarily only the first time. It pops up now and then in scenes which I have allready rendered with optix before.

It is also possible that an Optix Cache file is bad. In that case you have to delete it by hand.

On Windows it can be found in

C:\Users\YOURUSERNAME\AppData\Local\NVIDIA\OptixCache

Just delete the files there or rename them and the next time you render optix will create a new one.

I know this isn't the primary goal of OptiX but it is relevant when ray marching (sphere marching) signed distance fields so I figured I'd try. I created my own BVH for this originally but I was hoping to benefit from all the recent ray tracing work and RTX acceleration.

My initial attempt involved setting the optixTrace ray direction to 0, 0, 0 but this only triggers intersections for shapes where the ray origin is inside the AABB (makes sense). I then set the ray direction to inf, inf, inf which seemed to trigger intersection calls for every primitive regardless of AABB distances or reported tMax values.

Ideally, it would be nice to query only bounding boxes that are within tMax distance from the ray origin. This is obviously a different check than a ray-aabb intersection but I was curious if there might be some API flags/masks/functionality I'm missing that would allow for this. Direct access to the acceleration structure hierarchy could help here too but I didn't see anything about that in the programming guide.

It would be nice, and this is a common question, but unfortunately no, there is not currently a way to do a single nearest neighbor query or a single k nearest neighbors (KNN) query using the OptiX 7 geometry acceleration structures. These structures are currently limited to finite directional ray queries.

The site is secure.

The ensures that you are connecting to the official website and that any information you provide is encrypted and transmitted securely.

Mimicry--whereby warning signals in different species evolve to look similar--has long served as a paradigm of convergent evolution. Little is known, however, about the genes that underlie the evolution of mimetic phenotypes or to what extent the same or different genes drive such convergence. Here, we characterize one of the major genes responsible for mimetic wing pattern evolution in Heliconius butterflies. Mapping, gene expression, and population genetic work all identify a single gene, optix, that controls extreme red wing pattern variation across multiple species of Heliconius. Our results show that the cis-regulatory evolution of a single transcription factor can repeatedly drive the convergent evolution of complex color patterns in distantly related species, thus blurring the distinction between convergence and homology.

3a8082e126