Understanding that it’s in alpha stage, to what degree is the vulkan viewport actually usable?
What are some major areas for current viewport feature parity still missing?
citizen
Awesome! Any benefits for using two SLI (nvlinked) cards? Memory pooling, higher frame rate, et al.
malexander
It's nearing feature parity with GL, and over the course of the H20 production builds, we'll be finishing off those areas. The priority was to get all the core features working first, then move onto the non-critical or lesser used portions of the viewer. We have a reasonable amount of optimization work yet to finish, along with threading the updates and draws (it's all single threaded like GL right now; we have to completely sweep all GL calls out of the part of the pipeline Vulkan shares with GL first). Stability-wise, it's pretty good.
Here's a list of features that currently missing or incomplete (which is far smaller than the completed list):
- General performance needs work
- Shadows (all types)
- MatCap draw mode and material
- Flat shaded draw mode
- Bounding box draw mode
- Proper area light shading (point light model currently)
- Environment light shading needs work
- Foreground Images
- Volume Visualizer (all other visualizers and markers work)
- Fog (volume and uniform)
- Pose-state animation outlines missing
- Principled Shader and USD Preview Material displacement (MatX works)
- Some MaterialX texture issues
- Video color correction
- Texture paint
- MacOS support via MoltenVK (they just announced synchronization2 support last week, which was the last missing feature for HoudiniVK, so yay!)
- Some non-performance critical elements, like grids and handles, are still drawn with OpenGL.
I'll try to update this post periodically by striking out items from the above list as they're completed.
We also rewrote the part of the viewer that monitors and updates SOPs to get rid of all the ghost and missing geometry bugs; this is live whether you're running Vulkan or not. This should be a big improvement to everyday workflows.
Also, just because it's Beta doesn't mean you can't log bugs that you happen to find in the Vulkan renderer. One of the main reasons it was deferred until next release was because there wasn't enough time to thoroughly test everything, despite the vast majority of the work being complete.
malexander
It's nearing feature parity with GL, and over the course of the H20 production builds, we'll be finishing off those areas. The priority was to get all the core features working first, then move onto the non-critical or lesser used portions of the viewer. We have a reasonable amount of optimization work yet to finish, along with threading the updates and draws (it's all single threaded like GL right now; we have to completely sweep all GL calls out of the part of the pipeline Vulkan shares with GL first). Stability-wise, it's pretty good.
Here's a list of features that currently missing or incomplete (which is far smaller than the completed list):
- General performance needs work
- Shadows (all types)
- MatCap draw mode and material
- Flat shaded draw mode
- Bounding box draw mode
- Proper area light shading (point light model currently)
- Environment light shading needs work
- Foreground Images
- Volume Visualizer (all other visualizers and markers work)
- Fog (volume and uniform)
- Pose-state animation outlines missing
- Principled Shader and USD Preview Material displacement (MatX works)
- Some MaterialX texture issues
- Video color correction
- Texture paint
- MacOS support via MoltenVK (they just announced synchronization2 support last week, which was the last missing feature for HoudiniVK, so yay!)
- Some non-performance critical elements, like grids and handles, are still drawn with OpenGL.
I'll try to update this post periodically by striking out items from the above list as they're completed.
We also rewrote the part of the viewer that monitors and updates SOPs to get rid of all the ghost and missing geometry bugs; this is live whether you're running Vulkan or not. This should be a big improvement to everyday workflows.
Also, just because it's Beta doesn't mean you can't log bugs that you happen to find in the Vulkan renderer. One of the main reasons it was deferred until next release was because there wasn't enough time to thoroughly test everything, despite the vast majority of the work being complete.
LukeP
- other than performance what does the vulkan viewport do better in H20 than the GL viewport? There have been so many complains about the GL viewport in these forums in the last year - hope you’ve been tracking them - from losing selections, to accuracy, to shortcuts etc.
- does it also work in Solaris context? Ie can work with obj and Solaris context?
- Beside real-time rendering what are some of the benefits (once feature parity is attained) that we’ll reap from all your hard work?
Also are drawing and interacting with subs isolines on the horizon?
malexander
We also rewrote the part of the viewer that monitors and updates SOPs to get rid of all the ghost and missing geometry bugs; this is live whether you're running Vulkan or not. This should be a big improvement to everyday workflows.
malexander
It's nearing feature parity with GL, and over the course of the H20 production builds,
habernirmalexander
It's nearing feature parity with GL, and over the course of the H20 production builds,
Do you mean that this features will be publish in the next h20 production builds?
Andr
Is Vulkan viewport more performant in visualizing string attributes?
The current GL viewport is exceptionally slow.
malexanderAndr
Is Vulkan viewport more performant in visualizing string attributes?
The current GL viewport is exceptionally slow.
Unique strings are simply a bad case for display. We build a buffer containing all the string information and a point attribute to lookup the offset and size of the string. Usually there's a few dozen strings shared by multiple elements, so the text buffer is small. The other bad case is long strings, which because we generate 2 triangles per character times the number of elements, can also lead to sluggishness. Unfortunately there's very little the API can do here, because it's already done in a single shader.
I definitely think there should be other ways of visualizing strings - such as using solid colors and a legend for the few-string-many-elements case, highlighting/zooming to a given string, or being able to more easily inspect strings on primitives. Throwing up thousands of overlapping blue text strings seems very brute force and often not terribly useful.
malexanderhabernirmalexander
It's nearing feature parity with GL, and over the course of the H20 production builds,
Do you mean that this features will be publish in the next h20 production builds?
Certain features will make their way into H20 (like foreground images, lighting improvements, performance improvements). Some won't simply because they require more infrastructure changes and testing (like threading). But the plan is to make H20 reach parity with GL, and then make Vulkan the default renderer in the next version of Houdini.
malexanderhabernirmalexander
It's nearing feature parity with GL, and over the course of the H20 production builds,
Do you mean that this features will be publish in the next h20 production builds?
Certain features will make their way into H20 (like foreground images, lighting improvements, performance improvements). Some won't simply because they require more infrastructure changes and testing (like threading). But the plan is to make H20 reach parity with GL, and then make Vulkan the default renderer in the next version of Houdini.
LukePmalexanderhabernirmalexander
It's nearing feature parity with GL, and over the course of the H20 production builds,
Do you mean that this features will be publish in the next h20 production builds?
Certain features will make their way into H20 (like foreground images, lighting improvements, performance improvements). Some won't simply because they require more infrastructure changes and testing (like threading). But the plan is to make H20 reach parity with GL, and then make Vulkan the default renderer in the next version of Houdini.
Would the next version potentially include the RT renderer Cristin was talking about?