Mikko Mononen

@mikkomononen
77 Followers
34 Following
27 Posts
Coder and woodworker. Author of Recast&Detour and NanoVG. Previously at Epic Games, Unity, Tinkercad, Crytek, demoscene.

@lritter @sinbad

Similar case in text would generally mean that you have functionality inheritance in code, and data inheritance in assets. Narrows down where things might be.

IDEs are pretty good at browsing code (goto definition, etc). Browsing a BP inheritance not so smooth.

I think that is mostly tooling issue, not text vs visual scripting.

@lritter @sinbad
I have mostly worked on looking at other people's BP noodles, fairly senior designers. It was common that the BP hierarchy was like 6-7 classes deep, starting from something I see on level.

I generally had no problem figuring out the graphs, the main issue was where the specific graph (or data) was. E.g. I might know that some function I wrote got called, it might have bad params, and wanted to find that.

@lritter @sinbad
BPs are used both as "prefabs" (data inheritance, default values) as well as "OOP classes" (functionality, including overriding). It's fun at first, but it gets messy in larger projects when you have try to build abstractions for both.

@sinbad @lritter

On big projects, it gets really annoying to try to find where things are defined. BPs have both data and code and sometimes the hierarchies get very deep.

Another thing is refactoring, which gets nasty on those deep hierarchies. A small change can cause a lot of changed files (and in some cases it's impossible).

In general I think a lot of the issues stem from the code and data being in same hierarchy.

Both could be solvable with better tooling, though.

Procrastination level: went for a 15km hike to open VSCode. Maybe there's a function that gets written today, or maybe not.

@dotstdy @gorlak
Yeah, the unordered set behavior is super simple, things get tricky when you want specific ordering. I put the sorted array to the unordered, since we dont care during the merge.

Most use cases I have had to solve, the ordering did not matter, but it sure is annoying if your arrays shuffle around seemingly at random. Or that new things appear at random position.

@dotstdy @gorlak

I made a system a while back which used IDs for array elements, and stored a flag on the derived data if it was added/changed/deleted.

The merging was simply looking for runs of changes vs keeps, and favored the explicit changes. It was able to keep the changes at the beginning and end of the array (which was the most common case).

It did not go through a production, so I cannot say if others liked how it worked, I did :)

@dotstdy @gorlak The float approach is tricky, since every add-in-between needs a bit. There are ways to deal with that, but the fractional indexing may need arbitrary amount of bits.

Another way is to use ID per array element. Some of the solutions that does the array merging "right" feel surprisingly random in action (e.g. interlacing).

@aras Yeah. I also got some odd things, like not unrolling the tiny for loops in some cases. Struct would auto vectorize in the cases I checked (even if that is not a programming model :)).
@aras I tested some optimizations on Recast a while back. Recast uses "float foo[3]", style vec math, and passes values as pointers (add(float* a, float* b, float* res)). That prevented a lot of optimizations. The fastest way in my tests was struct, passed by value. Was testing release build, though.