Replies: 10 comments 12 replies
-
|
I am now at my development machine right now so just browsing source online, the ViewDependentSate.cpp is where the raversal mask would need be set up for casting/not casting shadows. Looking at the code there is a hardware mask of 0x1 that's set at: https://github.com/vsg-dev/VulkanSceneGraph/blob/master/src/vsg/state/ViewDependentState.cpp#L395 Mask shadowMask = 0x1; // TODO: do we inherit from main scene? how?
auto viewportState = ViewportState::create(VkExtent2D{shadowWidth, shadowHeight});
ref_ptr<View> first_view;
shadowMaps.resize(maxShadowMaps);
for (auto& shadowMap : shadowMaps)
{
if (first_view)
{
shadowMap.view = View::create(*first_view);
}
else
{
first_view = View::create(ViewFeatures(INHERIT_VIEWPOINT));
shadowMap.view = first_view;
}
shadowMap.view->mask = shadowMask;
shadowMap.view->camera = Camera::create();
shadowMap.view->addChild(tcon);
shadowMap.view->camera->viewportState = viewportState;
shadowMap.renderGraph = RenderGraph::create();
shadowMap.renderGraph->addChild(shadowMap.view);
preRenderSwitch->addChild(MASK_ALL, shadowMap.renderGraph);
}As I've added a TODO it'se clearly something I've added locally but didn't come across a requirement to make the control puiblic - I think you're the first peson to ask since I wrote these calsses. What would be required is public ViewDependentState member for setting the shadowMask rather than the use of local variable. With the shadowMask set you then would decorate subgraphs that you want to toggle on/off by deocrating them with a vsg::Switch node with the corresponding bits of the traversal mask set. Switching off recieving shadows would be more awkward as you'd need to extend the shaders to have a uniform for toggling on/off use of shadow maps. The vsgcustomshaderset would be the place to look for guidance on extending shader sets with custom uniforms and shaders. |
Beta Was this translation helpful? Give feedback.
-
|
Very informative, thanks. I had been using your OSG library for over a decade and this is my first foray into the VSG API. I'm a bit lost because in OSG shaders were an optional thing, but here they permeate the API and the framework. My real issue is going to be the receiving of shadows because it turns out - it's the flat earth below that I don't want the shadows. That is, I want to add them manually myself (for a variety of reasons), and use the normal VSG shadowing for the self-shadowing aspect. So, according to you above, I need to add a uniform and change the logic to the vsgcustomshaderset. I'll have a look at it. There are so many differences in the API that it's a bit daunting to try to find the counterpart in VSG for OSG tasks. For example, I want to draw my custom flat terrain shadows after the flat terrain, but before the objects on top of it with their self shadowing. Normally I'd use render bins. I didn't see render bins in VSG, so I'm spending a lot of time poking around examples. Ah well, this new API, and will take a bit of a learning curve. Thanks for your hard work! |
Beta Was this translation helpful? Give feedback.
-
|
Vulkan is so different from OpenGL that a scene graph written specifically for it's strengths ends up being quite different in places. Modern OpenGL is pure shader based like Vulkan is, so it's really just old OpenGL 1.x style fixed function pipeline scene graphs that will be significantly different. The VulkanSceneGraph has mechanisms in place for making life with a purely shader based workflow easier - this is where vsg::ShaderSet and vsg::GraphicsPipelineConfiguration come up, and there isn't an equivalent on the OSG side, one ends up having doing things manually and hardwired with shaders in the OSG. So in the domain of shaders the VSG should be easier. However, as much as the VSG tries to make things simpler to use Vulkan and shaders it's still a relatively large API and will require new ways of thinking about particular problems. For you usage case it may be best to take a step back and rather than try to recreate what you did with the OSG, perhaps aim for where you want your software to be in terms of features. It might be that things that were workarounds for OSG/OpenGL limitations might not be relevant today and you can just go straight towards a better quality solution without so many compromises. |
Beta Was this translation helpful? Give feedback.
-
|
I think I see what you mean. I guess if I keep in mind that VSG directly wraps Vulkan and not OpenGL, than there should be clues in how the Vulkan API operates that will illuminate your VSG framework and API. I was previously using the fixed pipeline in OSG and shaders for about 10%. This will be a big jump in my thinking. I'll take some time to look over the API as a whole and get familiar with the new terms (e.g. Pipelines, DescriptorSets, ViewDependentState, ShaderSets, etc.) And, as you say, there may be a more direct way to simply get the end result that I want with this framework without having to use the older OSG constructs. Thanks again. |
Beta Was this translation helpful? Give feedback.
-
|
When I started writing the VSG I began learning Vulkan and then wrapping Vulkan objects and then steadily built out the scene graph from there. Like I did with the OSG's close mapping between OpenGL and OSG classes, the VSG also has a close mapping between Vulkan and VSG classes. This means you can often just change a vsg:: prefix to a vk prefix and then look up the class online. The member variables in the VSG classes also mirror the ones you'll find in Vulkan CreateInfo structs. The VSG has also been architected for performance, so many OSG features like callbacks, bounding volumes, parents lists, node masks everywhere have been replaced with a far more pared down scene graph where scene graphs nodes are a fraction of those in the OSG. Essentially all the OSG features that were only occasionally used on some scene graph nodes are implemented via other means to avoid having everything and kitchen sink in the base Object and Node classes. However, you will find some capabilities like intrusive reference count with ref_ptr<>/observer_ptr<> re-implemented with C++17, and the Visitor pattern is here too, but expanded to include a ConstVisitor and with support for a far wider range of classes, not just scene graph nodes which the osg::NodeVisitor is limited to. The IO support for serializing to ascii or binary files is also far far easier to use and extend than the OSG's hotch potch of solutions. So while some stuff will be alien initially you should find some areas are just much cleaner and easier to use than the OSG equivalents. |
Beta Was this translation helpful? Give feedback.
-
|
I am using the ConstVisitor and it indeed is an expanded search with a far wider range of classes. I was trying to to gather up the source triangles for manually computing the terrain flat shadow triangles . I didn't see anything like OSG's TriangleFunctor, so I just derived from the vsg::ComputeBounds and override the applyDraw and applyDrawIndexed virtual methods. Even this didn't work right away because several of your ComputeBounds methods don't traverse downwards if they don't have to (bounds is already valid) - so I had to override them too! I'll get there. This project isn't that complex, and performance is not going to be an issue with the rendering in VSG that I'm seeing. The real reason why I wanted to manually produce the flat ground shadows is that very long shadows would degrade the shadow quality given that the shadow map would have to be spread over a potentially huge area. The self-shadowing areas are very confined and should be well defined for most objects. And, if I compose flat black terrain shadow triangles, it could go forever without having a texture size involved at all. So, using the native shadows for self-shadowing, and using a black flat triangle collection for the ground shadows would make sense. Thus the turning-off of the shadows on the terrain first so your shaders let me handle the ground shadows. It's a pity, I had everything working in OSG but WITHOUT the self-shadowing because we have the fixed pipeline for most things in our older software. I took a look at your VSG, and clearly - as they say - this is the way. I think this is the best time to get my feet wet and dive into your new API. Everyone seems heading in this direction! |
Beta Was this translation helpful? Give feedback.
-
|
One other thing of note. The casting of shadows is becoming more of a problem now. I added billboarded text to the scene (above some objects) and it does show (although there is a rendering issue from some angles), but it too casts shadows! I do not want the text to cast a shadow. No easy way around that, right? Was this intended? |
Beta Was this translation helpful? Give feedback.
-
|
The way to manage the text casting shadows would be to decorate them with a vsg::Switch as it would be with other subgraphs that you don't want to cast a shadow. Perhaps it would make sense to add a mask directly to vsg::TextGroup and vsg::Text, though in general I'm reluctant to keep adding features to existing elements when functionality can be achieve some other manage such as decorating with a vsg::Switch. The other way to do it is subclass from vsg::Text and implement a mask in the subclass. You usage case would make a neat VSG example, so if you fancy rolling up your sleeves and create a small example illustrating your usage case then we could us it as a unit test as well as help teach others how to go about this type of usage. |
Beta Was this translation helpful? Give feedback.
-
|
I've only been using VSG for a month, and even with a good strong OSG background, there is a big learning curve with this API. I basically began with the shadows example and went from there. The shadows are a bit of magic for me. Your example allows me to activate the hard shadows, and then models that I read_cast into the scene are indeed rendered with shadows. If I play around with the light position and compile some of the graph, the shadows change on the objects correctly. I also generally know what the switch node does (all or just some of the children can be considered at will. But in this case, it's not binary like I'm showing a "cover" of a box, or not. I don't even know what and when I would be switching anything for the shadows. I placed the terrain and a vehicle in the scene. I want BOTH to be visualized. I don't want to switch them on or off. Just some of the shadow casting (don't want the terrain to have a shadow on it, just the self-shadows). How could the Switch be used to do this? |
Beta Was this translation helpful? Give feedback.
-
|
You shouldn't need to compile the scene graph elements when you add/remove or move lights as they are managed dynamically by vsg::ViewDependentState for you. It's only new subgraphs that don't yet have Vulkan objects ceated for them that you'll need to compile. The casting of shadows for the text will have to managed by decorating with a vsg::Switch node and using the same traversal mask bit as the ViewDependentState is currently hardwired to use - 0x1 so bit zero is one you'd need to switch off for the Swtich node above the text. |
Beta Was this translation helpful? Give feedback.
-
|
Wow, that works great! This will easily allow me to stop certain things from casting shadows. I did the following which is what I think you are describing: I tried this with and without the switch and it definitely makes a difference. I thought vsg::Switch was only an enable/disable child kind of node, but I see there is a different addChild with a value. Didn't see this. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Makes sense. Still, these changes though are quite a tradeoff from OSG->VSG. That is learning curve + code complexity vs. performance ! |
Beta Was this translation helpful? Give feedback.
-
|
I understand that some things require a little more legwork in some cases, but in other cases it's less. However, it's the extra leg work that we all remember :-) To understand why some things a done differently try a sizeof(osg::Node) and sizeof(vsg::Node). All the extra bells added to all OSG objects adds quite a big overhead. |
Beta Was this translation helpful? Give feedback.
-
|
Lol, I'll take your word for it! |
Beta Was this translation helpful? Give feedback.
-
|
Now that I can prevent shadows from casting using the switch node, I decided to make a toggle for it. I create the switch and add the sub-graph with the mask as vsg::MASK_ALL. Later, to toggle a it off I change the mask to vsg::MASK_ALL & ~1. But the shadows still render. I thought maybe I had to recompile parts of the scene graph for it to take effect. I can’t get shadows to change from the initial state. What do I have to do to get VSG to recognize the mask has changed? |
Beta Was this translation helpful? Give feedback.
-
|
You only need to compile scene graph elements that have Vulkan objects, while dynamic GPU data like vertex arrays, uniforms and textures once created you can dynamically updating via the VSG's TransferTask. I've written about that dynamic data side at various times here and also written it up on the vsgTuotiral. The internal nodes of the scene graph like transforms and switches are pure CPU objects, there is no Vulkan/GPU mapping and no need for compiling and updating, the state of them is always current and the one used in RecordTraversals. This means when you update a mask it's affect will take immediate affect, same as for updating transform node matrices. So this leaves the question why what you are doing isn't working. What you describe should work fine, there must be something amiss in you scene graph setup or modifications but as I don't have your code or data I can't help say what this might be. |
Beta Was this translation helpful? Give feedback.
-
|
My MatrixTransforms for each model are placed under a vsg::Group, which is then placed under a single switch. I perform: m_placed_models_switch->children[0].mask = vsg::MASK_ALL & ~1; In visual studio, I can see not only that the mask goes from 0xffffffffffffffff to 0xfffffffffffffffe, but I can see that there is only one child of the switch, the parent group, and it in-turn has the four children MatrixTransforms. I must be missing something. The self-shadows are still there. |
Beta Was this translation helpful? Give feedback.
-
|
Could you modify the vsgshadow example to reproduce what you are doing and see if that recreates the problem you are seeing? Publishing this as PR would allow others to check the changes out and see if anything comes to mind. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, so your insight pointed me the way. I have indeed set up the switch, the group, and the children exactly as above. And, that switch was added to the scene directly. But, like your shadow example where you set up the "scene", but later add that as a sibling of a group that includes the lighting, I added the models group (not the switch) there as well. Looks like I just need to add the switch with models into the scene once. Does it matter if the switch with the models is a parent or sibling to the directional lighting node? |
Beta Was this translation helpful? Give feedback.
-
|
The way that the lighting is managed in the VSG is per vsg::View, with all the lights below a vsg::View being collected and placed in a light uniform that holds all the lights in eye space along with the details used for shadow mapping. It doesn't specifically matter where the lights are placed for this purpose as if they are traversed they will be part of the view's lighting. The placement of the vsg::DirectionalLight depends upon how you want to manage your scene. If a light source is part of the scene - like sun position or a street light then you might want to put it in the part of the scene graph that represents your scene. If you have a headlight or want the light that conceptually is part of the viewer/environment then keep it just below the vsg::View and a sibling to topmost node that represents your scene. If you want to toggle on/off a light you could potentially stick it under a vsg::Switch or just change the intensity value of the vsg::Light to zero. So you have a range of options of how you can do things, you may even want to mix and match - such as have a directional sun light subgraph attached directly as a child of the vsg::View and then have point light sources that part of scene subgraphs - the loaders might even populate subgraphs with lights. |
Beta Was this translation helpful? Give feedback.
-
|
Very cool. There is code, there are examples, there are header files, and there are discussion groups. Is there a short document that has these nuggets of information (e.g. lights are collected for each vsg::View and stored in a light uniform). Especially with those parts of VSG where there is something being done for you beyond normal vulkan stuff (e.g. shadows, etc.) and were specific design choices made under the hood that have to be "kept in mind" ? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I'm playing around with the vsgExamples and the vsgshadows project in particular. With only a few options it can depict hard shadows very nicely on four different shapes sitting on a flat sheet. I'd like to find a way to prevent just ONE of the four shapes from participating in both casting and receiving shadows. I did not see another example that does this, and I've tried several approaches to no avail. Anyone know of a simple approach to prevent just one shape/subgraph of the scene from participating in the shadow process?
Beta Was this translation helpful? Give feedback.
All reactions