can't get any surface to render except as opaque black
ExpandingMan opened this issue · comments
I cannot seem to get any surface to render with any appearance other than opaque black. An example of this can be seen in the following rendering of a pair of triangles, which looks correct other than seeming to ignore the set vertex colors.
This example is from reproducing the ANARI-SDK C tutorial. However, more broadly, even though all geometry looks correct, nothing I have tried has given anything other than opaque black (i.e. RGBA(0,0,0,1)) where the geometry appears. Some of the pixels on the boundaries are various shades of grey, but they are all r = g =b with alpha of 1.
For context, my experiments have been in writing a Julia wrapper for anari. I of course realize that there is a good chance that any problem I'm experiencing is a bug in my wrapper, however I have by now done quite a lot to rule that out, and more importantly, I can also reproduce this issue using only direct calls to the C library, the example for this (which I think should be quite readable even to anyone who has never seen Julia) can be found here. Again, this follow the ANARI-SDK tutorial and I have attempted many subtle variations thereof.
Here is a partial list of things I have tried:
- All allowable formats for the frame color type via the parameter
channel.color. - All available renderer types.
- Triangle and sphere geometries.
- Setting the
vertex.colorattribute in the geometry to colors, of multiple formats with or without the alpha channel. - Setting geometry color using an
image1Dsampler object, as in the visrtx tutorial. - Directional and point lights of different power.
- Physically rendered material with several different sets of parameters.
Because nothing I do seems to have any affect, I think the most likely culprit is something to do with the image format, however I'm clearly not interpreting the format in a completely bogus way since I always see what looks like correct geometry, it just looks all black. (Again, I get some greys.)
Here is log from the ANARI-SDK tutorial I have referenced above:
┌ Debug: ANARI: initializing VisRTX device
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Debug: ANARI: running on GPU 0 (NVIDIA GeForce RTX 4090)
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Info: ANARI: OptiX message [4][KNOBS]:
└ All knobs on default.
┌ Info: ANARI: OptiX message [4][DISKCACHE]:
└ Opened database: "/var/tmp/OptixCache_expandingman/optix7cache.db"
┌ Info: ANARI: OptiX message [4][DISKCACHE]:
└ Cache data size: "53.4 MiB"
┌ Debug: ANARI: Compiling 'debug' renderer
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Info: ANARI: OptiX message [4][DISKCACHE]:
└ Cache hit for key: ptx-2804850-key5b7c6ea927197cadb9e7ed265ac6c57f-sm_89-rtc1-drv535.104.05
[ Info: ANARI: OptiX message [4][COMPILER]:
┌ Debug: ANARI: Compiling 'raycast' renderer
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Info: ANARI: OptiX message [4][DISKCACHE]:
└ Cache hit for key: ptx-4561964-key412173ee96572c9d2f25487cb0558cad-sm_89-rtc1-drv535.104.05
[ Info: ANARI: OptiX message [4][COMPILER]:
┌ Debug: ANARI: Compiling 'ao' renderer
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Info: ANARI: OptiX message [4][DISKCACHE]:
└ Cache hit for key: ptx-6782164-key9b81e8c6131ec208368efe92f9cc6e06-sm_89-rtc1-drv535.104.05
[ Info: ANARI: OptiX message [4][COMPILER]:
┌ Debug: ANARI: Compiling 'dpt' renderer
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Info: ANARI: OptiX message [4][DISKCACHE]:
└ Cache hit for key: ptx-4513301-keye1363d3ec33b8a66922a70ecead43b7e-sm_89-rtc1-drv535.104.05
[ Info: ANARI: OptiX message [4][COMPILER]:
┌ Debug: ANARI: Compiling 'scivis' renderer
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Info: ANARI: OptiX message [4][DISKCACHE]:
└ Cache hit for key: ptx-6824677-key7a1422020fdd46f26fb6b5b21738d8d1-sm_89-rtc1-drv535.104.05
[ Info: ANARI: OptiX message [4][COMPILER]:
┌ Debug: ANARI: Compiling 'test' renderer
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Info: ANARI: OptiX message [4][DISKCACHE]:
└ Cache hit for key: ptx-1059265-key6026bc4f5439bd67a1b9dd7134d491a6-sm_89-rtc1-drv535.104.05
[ Info: ANARI: OptiX message [4][COMPILER]:
┌ Debug: ANARI: Compiling custom intersectors
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Info: ANARI: OptiX message [4][DISKCACHE]:
└ Cache hit for key: ptx-999565-keyd78be9e21859c255cbfa3b1306bbd8e5-sm_89-rtc1-drv535.104.05
[ Info: ANARI: OptiX message [4][COMPILER]:
┌ Info: ANARI: OptiX message [4][DISKCACHE]:
└ Cache hit for key: ptx-11625-key5212c42a82015e68163c7c96aefe3628-sm_89-rtc1-drv535.104.05
[ Info: ANARI: OptiX message [4][COMPILER]:
┌ Warning: ANARI: making private copy of shared array (type 'ANARI_FLOAT32_VEC3') | ownership: (1:3)
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:33
┌ Warning: ANARI: making private copy of shared array (type 'ANARI_UFIXED8_VEC4') | ownership: (1:3)
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:33
┌ Warning: ANARI: making private copy of shared array (type 'ANARI_UINT32_VEC3') | ownership: (1:3)
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:33
┌ Debug: ANARI: freeing privatized shared array data
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Debug: ANARI: freeing privatized shared array data
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Debug: ANARI: committing indexed triangle geometry
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Debug: ANARI: visrtx::World will add zero instance
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Debug: ANARI: visrtx::World found surfaces in zero instance
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Debug: ANARI: visrtx::World found lights in zero instance
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Debug: ANARI: visrtx::World rebuilding BLASs
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Debug: ANARI: visrtx::Group building triangle BVH
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Debug: ANARI: visrtx::Group building curve BVH
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Debug: ANARI: skipping BVH build
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Debug: ANARI: visrtx::Group building user BVH
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Debug: ANARI: skipping BVH build
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Debug: ANARI: visrtx::Group skipping volume BVH build
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Debug: ANARI: visrtx::World building surface BVH over 1 instances
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Debug: ANARI: visrtx::World building surface gpu data
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Debug: ANARI: visrtx::World building volume BVH over 0 instances
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Debug: ANARI: skipping BVH build
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Debug: ANARI: visrtx::World building volume gpu data
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Info: world bounds:
│ world_bounds =
│ 6-element Vector{Float32}:
│ -0.50000036
│ -0.50000036
│ -3.5762793f-7
│ 0.50000036
│ 0.50000036
└ 3.5762793f-7
┌ Info: ANARI: OptiX message [4][COMPILER]:
│ Info: Pipeline statistics
│ module(s) : 3
│ entry function(s) : 7
│ trace call(s) : 6
│ continuation callable call(s) : 0
│ direct callable call(s) : 0
│ basic block(s) in entry functions : 20991
│ instruction(s) in entry functions : 153945
│ non-entry function(s) : 0
│ basic block(s) in non-entry functions: 0
│ instruction(s) in non-entry functions: 0
└ debug information : no
┌ Debug: ANARI: Pipeline Create Log:
│ Info: Pipeline statistics
│ module(s) : 3
│ entry function(s) : 7
│ trace call(s) : 6
│ continuation callable call(s) : 0
│ direct callable call(s) : 0
│ basic block(s) in entry functions : 20991
│ instruction(s) in entry functions : 153945
│ non-entry function(s) : 0
│ basic block(s) in non-entry functions: 0
│ instruction(s) in non-entry functions: 0
│ debug information : no
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Debug: ANARI: freeing privatized shared array data
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Debug: ANARI: freeing privatized shared array data
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Debug: ANARI: freeing privatized shared array data
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Debug: ANARI: freeing privatized shared array data
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
┌ Debug: ANARI: freeing privatized shared array data
└ @ Anari ~/.julia/dev/Anari/src/Anari.jl:37
Any suggestions of different approaches to try would be much appreciated, as at this point I'm rather thoroughly stumped. Thanks!
Hi! Sorry for the delay -- have you tried setting ambient lighting to something other than the default 0? You can do this on the renderer with the ambientRadiance float parameter.
I'll also note that there was a copy/paste bug with the point light position parameter being accidentally normalized, so depending on where the light is in relation to the scene, it may have not appeared in the right place. This is fixed on the next_release branch.
Another thing to keep in mind as you're getting up to speed is to compare with the raycast renderer, which has a fixed lighting model (i.e. ignores all lighting) -- this can be helpful when wanting to see what the raw geometry/volumes look like indepenant of all lights in the scene (including ambient lighting).
The integration with Julia looks interesting! Once we get through some of these issues, I'd love to learn more about it. 😃
That worked! 😄
Apparently the point light bug was my main problem. I could have sworn I tried directional lights more than once, but maybe I had it upside down.
Another thing to keep in mind as you're getting up to speed is to compare with the raycast renderer, which has a fixed lighting model (i.e. ignores all lighting) -- this can be helpful when wanting to see what the raw geometry/volumes look like indepenant of all lights in the scene (including ambient lighting).
A documentation page explaining this kind of thing would be very helpful. Details such as that are not (I don't think?) described by the ANARI spec.
The integration with Julia looks interesting! Once we get through some of these issues, I'd love to learn more about it. 😃
It's very early and experimental, but I tried to do it in a very general way so I think ensuring it covers the entire library is straightforward. I have long bemoaned the lack of graphics "middleware": there are very few options between writing raw vulkan code and some huge and elaborate thing like a game engine. ANARI therefore caught my attention when it showed up in my news feeds because, as far as I know, there are very few (if any) alternatives. It seems there is potential for it to play a very useful role in an ecosystem like Julia's. I could, for example, imagine it being a great back-end for rendering 3D images for visualization frameworks such as Makie; but for the time being it's just me messing with a wrapper. 🙂
A somewhat off topic note, but rather important for any more serious use of VisRTX: the download wall and possibly license for OptiX are potentially a major problem for anyone looking to use it. For example, in the short term at least it will prevent me from making this wrapper easily installable as a Julia package. I haven't tried to figure out the license terms, so I don't know how deep this problem actually goes, but it would go a long way to making people more willing to use VisRTX if the needed optix headers were more easily available. If the license prevents re-distributing the optix headers, visrtx would be DOA for most use cases. I'd like to assume that it was intended for optix to follow a similar usage pattern to CUDA, but I don't know where that leaves me in terms of creating automated build tools,
A documentation page explaining this kind of thing would be very helpful. Details such as that are not (I don't think?) described by the ANARI spec.
Touche 😄, I'll add something to the README in the next release. Renderers always seem to be in flux, but a basic explanation of each is more stable.
It's very early and experimental, but I tried to do it in a very general way so I think ensuring it covers the entire library is straightforward. I have long bemoaned the lack of graphics "middleware": there are very few options between writing raw vulkan code and some huge and elaborate thing like a game engine. ANARI therefore caught my attention when it showed up in my news feeds because, as far as I know, there are very few (if any) alternatives. It seems there is potential for it to play a very useful role in an ecosystem like Julia's. I could, for example, imagine it being a great back-end for rendering 3D images for visualization frameworks such as Makie; but for the time being it's just me messing with a wrapper. 🙂
Seems like some quick progress, which is exciting for sure. Really glad to see ANARI able to add value, especially early on in its life. Makie seems to have support for RadeonProRender, which means someone has already integrated with an "ANARI-like" API. There's a really old RPR implementation for ANARI, which if updated to the latest SDK could make a compelling reason to switch to ANARI. Time will tell!
A somewhat off topic note, but rather important for any more serious use of VisRTX: the download wall and possibly license for OptiX are potentially a major problem for anyone looking to use it.
This is an issue that is not lost on me, and I empathize with it quite a bit. For the short-to-medium term, VisRTX will still be OptiX based, but we have talked about possibly moving to Vulkan for a variety of reasons (which will be a non-trivial amount of work). There is the VisGL backend also in this repo, and this repo will likely be the collection point for other devices we are working on (e.g. IndeX). Regardless, this is good feedback and I can keep an eye on ways to make it easier to get VisRTX building in more places.
I'll go ahead and close the issue, but feel free to keep the discussion going if you want!
we have talked about possibly moving to Vulkan for a variety of reasons (which will be a non-trivial amount of work)
When I first saw this I figured that's what it was. I do think that would be very interesting, especially since then presumably you could have something a lot more like a single implementation that runs on any piece of hardware. Again, the dearth of anything resembling graphics "middleware" seems crazy. I suppose there isn't a huge audience, but particularly as opengl seems much like a thing of the past, one would think there'd be lots of people who don't want an entire game engine (or blender or whatever) but also don't want to spend the rest of their lives figuring out which memory type to use in thousands of lines of low-level vulkan code.
Regardless, this is good feedback and I can keep an eye on ways to make it easier to get VisRTX building in more places.
It might be helpful if, as a not untypical anecdote, I describe the situation I'd be presented with if I showed this wrapper off to the Julia community. The Julia package manager effectively carries around it's own linux distribution based on binaries built and distributed as Julia packages, using a tool called BinaryBuilder. Here is the script I use to build VisRTX. Because this requires the optix headers, it cannot be fully automated. Therefore, I could not provide an easy method for someone to install the ANARI wrapper, they'd effectively have to build ANARI themselves. This is basically the same situation that any linux distro maintainers would be in, they can't provide any of the needed binaries, so you wouldn't even be able to pacman -S visrtx (indeed it seems there is a broken AUR package). That's a lot of manual effort to just install a library.
By contrast, all you need is the driver and CUDA can be fully installed for you. Of course, CUDA also has a proprietary license, so perhaps it was intended that ANARI could be distributed in a similar way, but there would have to be clear instructions somewhere on what's permissible in a build process. It's not apparent to me whether optix can just be bundled in a tarball, whether it has the appropriate license docs etc or not. The fact that it is behind a download wall makes me assume no. I don't think it's being overly dramatic to say that needing an account with nvidia to get a component of visrtx renders it completely dead in the water for some large class of people that might otherwise be interested in using it.
Therefore, I could not provide an easy method for someone to install the ANARI wrapper, they'd effectively have to build ANARI themselves.
Is it possible to have the ANARI bindings for Julia be stand alone (perhaps defaulting to using the helide device that comes with the SDK), so VisRTX isn't entirely the limiting factor? The ANARI-SDK itself (i.e. the API actually being used) is nicely Apache 2.0, meaning it should be fine to be distributed.
Is it possible to have the ANARI bindings for Julia be stand alone (perhaps defaulting to using the
helidedevice that comes with the SDK), so VisRTX isn't entirely the limiting factor? The ANARI-SDK itself (i.e. the API actually being used) is nicely Apache 2.0, meaning it should be fine to be distributed.
I suppose but frankly I only think anyone would be interested in using it with the GPU. If it's just a wrapper of a test implementation and you had to go through a bunch of hoops to actually use the GPU, I don't think anyone would bother, though correct me if I'm misunderstanding the suggestion.
You have that right -- and I agree. As more implementations come online, my hope is that there's more GPU renderer portability available beyond VisRTX/VisGL. RadeonProRender + OSPRay's forthcoming GPU backend will become interesting in the near term, but those are immediately usable right now. I also have an experimental back end that uses Cycles standalone from Blender (here), but it isn't fleshed out enough to do "real" work with just yet.
Fortunately the API for all these future backends is just ANARI, so there isn't any adaptation really needed to use them -- just whatever is needed to deploy binaries.
We can't get a Vulkan implementation up overnight, but you are heard loud and clear. :)
Cool, well it's a little disappointing to hear there is such a barrier to this in the near-term, but good to hear the issue is understood. My take on the AMD version was that it was a wrapper around ProRender... it didn't look that well maintained but it also looks like a thin wrapper, so maybe that's a misconception. That would probably be easier to deal with but I don't have any AMD cards right now so I haven't touched it.
My take on the AMD version was that it was a wrapper around ProRender
That's exactly what it is. It's a similar strategy that OSPRay took because for the time being those renderers have existing software they have to support through their existing API. Opening a GitHub issue over there saying "I would use this if it was up to date" might go a long way.
That would probably be easier to deal with but I don't have any AMD cards right now so I haven't touched it.
AFAIK it doesn't have a hard AMD GPU requirement, so it may be more usable that you'd think (as long as it's implementation is up to date with the SDK, of course).