tag:blogger.com,1999:blog-1994130783874175266.post4199957923655765433..comments2024-03-28T17:36:55.759+01:00Comments on bitsquid: development blog: Visual Scripting the Data-Oriented WayNiklashttp://www.blogger.com/profile/10055379994557504977noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-1994130783874175266.post-79469920624948797742022-10-14T17:14:31.027+02:002022-10-14T17:14:31.027+02:00Niyama is Sanskrit for "rules, instructions, ...<a rel="nofollow" href="https://yogauntold.com/niyama-of-yoga/">Niyama</a> is Sanskrit for "rules, instructions, or observances." The niyamas appear in Hindu and Buddhist texts, but are best known as the second branch of the eight branches of yoga as described in Patanjali's Yoga Sutras.<br />Harry Jacsonhttps://www.blogger.com/profile/05778820611013129784noreply@blogger.comtag:blogger.com,1999:blog-1994130783874175266.post-45885609496144683912021-12-18T16:05:39.008+01:002021-12-18T16:05:39.008+01:00เว็บสล็อต<a href="https://www.5g999.co/slot" rel="nofollow"> เว็บสล็อต </a>Dara Kaewhttps://www.blogger.com/profile/11109872795468567865noreply@blogger.comtag:blogger.com,1999:blog-1994130783874175266.post-49236044966476979102011-03-16T09:12:21.632+01:002011-03-16T09:12:21.632+01:00Dynamic means they can change, and each instance g...Dynamic means they can change, and each instance gets a separate copy. A typical example would be a Counter node with Increase and Decrease outputs. The Counter node would use a dynamic int to store the current value of the counter.<br /><br />At data compile time, all nodes specify how much dynamic memory they want (the Counter node wants four bytes) and they get an offset back that specifies where to find their memory in the dynamic data block. The size (and initial value) of the dynamic memory block is determined.<br /><br />When a flow graph is instanced, a copy is made of that memory and all subsequent operations on that instant use the dynamic copy to store the data.Niklashttps://www.blogger.com/profile/10055379994557504977noreply@blogger.comtag:blogger.com,1999:blog-1994130783874175266.post-53749952954275552082011-03-15T12:16:55.003+01:002011-03-15T12:16:55.003+01:00Thanks for the reply Niklas. I love how the dynami...Thanks for the reply Niklas. I love how the dynamic areas can be deleted in one foul swoop. Makes for very cheap GC.<br /><br />Still missing the distinction between your static node areas and your dynamic (but precomputed at compile time) areas.Anonymoushttps://www.blogger.com/profile/06340403723350864929noreply@blogger.comtag:blogger.com,1999:blog-1994130783874175266.post-37805360529183215572011-03-14T11:36:31.248+01:002011-03-14T11:36:31.248+01:00A vtable might be good idea as you suggest. I don&...A vtable might be good idea as you suggest. I don't think it has that much impact on performance, but as you say in some cases it may make for nicer code.<br /><br />Yes, I already think of the offsets as pointers. Typically the script is associated with an entity or a level and lives as long as that entity/level lives. When it dies, the entire dynamic area is deallocated at once. The dynamic area does not grow or shrink... the allocation of the dynamic data is done at "compile time".<br /><br />Nodes can be different sizes. So yes, some of the dynamic data that isn't could be moved to the static area to save dynamic memory. I've thought about that. The downside is that the nodes will have to check on every variable access if it is dynamic or static, so it will make the code a lot more complicated and branchy. So far it hasn't seemed worth it.Niklashttps://www.blogger.com/profile/10055379994557504977noreply@blogger.comtag:blogger.com,1999:blog-1994130783874175266.post-42149382658140792852011-03-14T02:27:52.997+01:002011-03-14T02:27:52.997+01:00Nice write up. I really like your phrase "fil...Nice write up. I really like your phrase "file formats for memory" - this is a brilliant way to explain these ideas to others.<br /><br />Instead of switching on the node type, you could index into a jump-table/vtable although the switch should compile down to a jump too but there is often a range check that cannot be removed without compiler assistance (like GCC's computed goto). This kind of thing might help to alleviate any troubles with OO dogma.<br /><br />You could perhaps think of the offsets as pointers. What are pointers anyway? They aren't always machine addresses. These things (compressed, less pointerful/pointy data structures) resemble private heaps (or memory spaces/arenas). The static ones are the best because they need such little overhead in terms of maintenance structures like free lists. The dynamic arena you describe would perhaps need no free list either if the Flow script is short lived and the whole dynamic area can be reset when the script has executed.<br /><br />Are your nodes all the same size? Perhaps if they were different sizes then some of the dynamic data (that isn't truly dynamic) could be moved into the node area?Anonymoushttps://www.blogger.com/profile/06340403723350864929noreply@blogger.comtag:blogger.com,1999:blog-1994130783874175266.post-46075134252784553402010-09-21T07:06:47.241+02:002010-09-21T07:06:47.241+02:00Yes, in theory you could run the flow graph on an ...Yes, in theory you could run the flow graph on an SPU and let it generate a list of action messages to be processed by the PPU. (You also need to let the flow graph query the world, which is trickier, but doable.)<br /><br />But I don't think you would gain much from that, because the nodes don't really do much besides run actions. I.e., processing the action messsages on the PPU will take almost as much time as running the flow graph. So you haven't really gained anything by involving the SPUs.<br /><br />As I see it, the flow graph is a high level system that connects a bunch of low level systems. It is in these low level systems that the actual processing happens and they are properly multithreaded.<br /><br />In the design, I am consciously enforcing this perspective, by not adding anything that is compute-heavy to the flow graph itself. For example, there is no update() call to flow graphs. Flow graphs only react when triggered by a specific event. Everything that needs to tick every frame is handled by a lower level system.<br /><br />For animation for instance, we have three systems on a lower level than the flow graph. AnimationPlayer, that evaluates curves into poses. AnimationBlender, that blends multiple poses together. And AnimationStateMachine which runs a state machine (also edited with a graph editing tool). All of these systems are multihtreaded.<br /><br />The flow graph talks to the animation state machine by sending events (32 bit string hashes) such as "jump" or by setting variables, e.g. "jump_height = 2". So the flow graph can drive animation without actually doing much processing by itself.Niklashttps://www.blogger.com/profile/10055379994557504977noreply@blogger.comtag:blogger.com,1999:blog-1994130783874175266.post-21147319303067033982010-09-21T05:59:53.106+02:002010-09-21T05:59:53.106+02:00This looks like a really interesting and useful to...This looks like a really interesting and useful tool, and I could see it being used for simple AI and Animation behavior flow as well, in which case I could also see needing to multithread it (you'd already stated that you can push the entire flow graph off to the SPU for processing pretty easily).<br /><br />In the cases where a flow graph needs to talk to another system, couldn't you extrapolate out the system interactions into a switchboard / message passing system? Would that make sense or would even when using Flow to diagram animation / behaviors would that add too much overhead?Jeff Wardhttps://www.blogger.com/profile/02351657243905589993noreply@blogger.com