This is a collection thread for weird things in VL.Stride
The purpose of this thread is to collect pitfalls when starting to use VL.Stride, so devs can get a snapshot what parts of this mighty nuget could irritate the users out there in the world
Most of them are not bugs, but rather quirks, that can maybe ironed out eventually. The problem is, those quirks might become invisible to experienced users rather quickly, but remain hard to understand for beginners and first-time-users.
So please spit out all your foolish attempts to wrangle the beast of a thousand pins.Maybe, just maybe your struggle will help to inform a high level node worthy of the name and credit.
SceneWindow works with an internal fallback OrbitCamera, but SceneTexture does not - so the claim that the two are “the same” is not true, in fact, SceneTexture simply stays blank without an additional Camera -> yes
Quad does not expose the BlendState Description
Setting a most basic ViewProjection to a Renderer is surprisingly convoluted
While the naive handling of AspectRatio seems easier now, I could not find a way to retrieve the corresponding transform matrix of Quads or Renderers (for hittests for example)
Please join in, if you find more. The more, the merrier.
Let’s crowd force the insights!
good point, it could have a default view. but for the orbit camera to work, it needs a window with input devices, that is the reason why it doesn’t have one. But there is also a node called Camera that you can use.
best don’t use Quad, it is an experimental node that we are not sure about and it will most likely be removed.
when you want to do low-level rendering on your own, like in vvvv beta dx11 use a RenderEntity and build a graph with Groups and the Renderers, like QuadRenderer or MeshRenderer that have all of these settings as input. or go the stride entity/material way when you need lighting.
you only need an entity and add a CameraComponent. our new render engine is based on the Entity/Component model, so any entity can become your camera, which is 1-2 nodes more but includes many new scenarios that might make things much simpler than it was in vvvv beta. it just takes a while to get into the enity/component way of thinking.
these are all part of the components, which represent the data objects/state of an entity. so the world matrix of an entity is in the TransformComponent and the camera matrix is in the CameraComponent. both can be retrieved via their respective getter.
but in general, i agree, you have to read a bit more documentation and understand more of the system than in vvvv beta, but once you get it, it is (arguably) simpler and has a better structure.
did you read the info in the engine intro patches? if yes, what would you add or improve so that the next users will not stumble over the things you encountered?
@tonfilm
aren’t you interested in small things that first time vl.stride users feel to be cumbersome, quirky or hard to find?
because this thread is dead on arrival, if responses like “you didn’t read the manual enough” or “it was tagged experimental, your fault if you use it” are the norm.
my notion of it is two-fold. at least half of the things i mentioned will “go away” for me, once I found their solution, used the correct node successfully and conceptualized them in a correct way (a lot of the things on the list might even seem stupid in hindsight, hehe).
the other half might stay cumbersome. but, and this is important: this collection is not about me trying to showcase my lack of understanding, but about helping you to cater for the next user who is diving in. and inviting others to share their particular brick in the wall.
I don’t expect anyone to “fix” them right away, or even explain a solution (if you do though: dope). this thread is about stuff that slips through the categories of Bug and Question. neither do I presume that there is something fundamentally wrongabout VL.Stride (ECS is top notch)
it’s just that VL.Stride does not feel high-level at at all just yet (july 2021). so collecting /mildlyannoying first-timer impressions seems the call of the hour
With that out of the way, let me just continue to list things, that scraped me when using VL.Stride, where the edges are still rough
sometimes render windows cannot be closed with the X, but only from the taskbar. no idea why
finding a corresponding WindowScene node to a renderer is hard, and in bigger patches and a few open helppatches close to impossible
finding a corresponding window to WindowScene is cumbersome. was only possible by renaming it,
Add and AlphaBlend outputs have different names, which makes replacing them weird. I am missing Multiply and AlphaAdd
thanks for the list, we absolutely value every feedback we can get. so if you want this to be a thread for things a beta user stumbles upon, we’ll wait whether we can gather more points from other users as well and can then address them all at a later point.
I can understand @velcrome in some points, as i pass a little the same as many of us migrating to stride.
My main clues were this:
-Understanding entities and components.
-Understanding viewports and cameras.
-Low level pipeline in materials and meshes.
-No editor helpers for cameras and light without debug view.
-instances not unified ( color , transform needs dif nodes )
-differences between all the kind of windows (scenewindow, scenetexture,texturewindow, etc…
-Depth and blending.
-Document texture handling.
When your mind is fixed in way of work, expects the rest work as we think. But , Gamma is not beta. as much as many of us wonder to get the same feeling, Gamma is another thing,another feeling, is not high level at all, of course, as make you learn many concepts from C# programming and .NET to acomplish many tasks, but that learning curve is a must when you are dealing with all this libraries to work together in a patching enviroment, also, entity/component system is quite new for beta users, once you understand it makes the structure and the workflow really good , every patch takes you a little more of time to understand, and VL.stride is still borning in my opinion,sometimes boring for those who want a direct result, the best is to find wich situations are better for you to use it, and if not , you will always have dx11 in beta.
But i must say that low level in stride let you have a little hole of freedom for developers and users that want to extend it, we could have less nodes, that does the things more directly to do the same as beta. but as the complexity of the system grows, make also understand how this really works ,while devvvvs are polishing it. Well for new users…? yes this will be a rough road… no video documentation, no step by step guide, but well, you come from beta… in the beginning F1 was not there for many of the nodes. that means we need some years, maybe , meanwhile we can dig in into it. Stride is powerful and complex, even as an engine, is easier to use it in gamma than by itself.
-In my opinion we lack a channel of video docs that help beta users to do same things than in beta in a clean way, mostly for those irritated jejeje… i mean not random examples. just covering the main topics, but if so, who will do it?
-Also for new users, we lack a series of “attractive” videos with some fancy results to get more people diving with us.
-Even maybe a monthly twitch session to solve main topics just about stride will be interesting.
Beta was in the beginning not easy for me, i expected gamma was, after 10 years of beta user. but i learned to start to learn again. if you have time…
Everything you know is wrong.
