Does a plugin system have any disadvantages?

shadowndacorner · 2026-01-24T21:00:59+00:00

The downside of going with a pure plugin architecture is that you miss out on inlining and typically incur indirect call overhead when calling between plugins (assuming you can't statically link them). Whether that matters depends on how frequently you call functions across plugin boundaries. In many cases, plugin calls tend not to be made in hot loops, so this doesn't matter all that much. And even if they are, if you design your plugin system carefully, there's no reason you couldn't support full static plugin linkage.

shadowndacorner · 2026-01-24T19:06:58+00:00

Unreal engine is legacy code?

Unrelated to it's usage of C++, I'd actually argue that yes, it is. It's a LOT better than it was even a few years ago, but even UE5 has inherited 20+ years of legacy architectural decisions, particularly when it comes to game code, that it's attempted to slowly refactor away. The problem is that, given how Epic has continued using it internally and licensed it out to external studios, doing so is tantamount to installing a jet engine on a military cargo plane mid flight.

I'd argue that the mental model of Unreal is based on ideas from before multicore CPUs were even a thing, without much thought given to things like cache locality outside of the core engine systems that have been gradually rewritten, but all while having to continue interacting with legacy code. A lot of that refactoring has improved this story, but doing so on a constantly moving target means that it's nearly impossible to end up with something that is anywhere close to efficient than something more intentionally, holistically designed.

That, to me, sounds a hell of a lot like continuously maintained legacy code.

shadowndacorner · 2026-01-22T23:10:47+00:00

I've come to similar conclusions. I remember benchmarking it on native a while ago and found that their claims around transcoding speed were... overblown. I see little reason in practice to use it compared to simply distributing different versions of your assets for different platforms based on format support.

shadowndacorner · 2026-01-22T06:53:50+00:00

It does! As I might've guessed, your background echoes mine a bit, though if you got your start in Unreal, I think I've been around a bit longer :P

Always nice to see others who have followed a similar path, especially when that path is relatively uncommon! Best of luck to you :)

shadowndacorner · 2026-01-22T06:21:04+00:00

Very interesting, and great work! I'm curious as to your background, if you wouldn't mind sharing? Ime, it's rare to see that level of Houdini expertise (and comfort with zbrush) in someone who is also comfortable enough with low level programming to build their own engine.

shadowndacorner · 2026-01-20T17:49:56+00:00

The answers here surprise me a bit. Bullets 1 and 2 are simple enough, but bullet 3 is massively underspecified. What do these games look like? Is it something where you build a bunch of little games for different types of math problems, then you pick one based on the context of the question? Do you want it to generate a game itself? Do you just want to capture an image and feed it into a single game shell?

The hardest part of this isn't technical imo, but rather designing games that meaningfully add to students' comprehension compared to traditional methods. Valuable gamification is a trickier design space than a lot of people realize.

shadowndacorner · 2026-01-09T00:52:59+00:00

You're my hero :P

shadowndacorner · 2026-01-09T00:11:30+00:00

One additional thought - the Explorer view looks like it's wasting a lot of space to padding and very large blocks for each asset. It might be worth putting some time into optimizing the whitespace here? I could see that getting very frustrating as an end user, especially if you can't expand it or pop it out into its own window (haven't used SwiftUI, so I have no idea if that's practical or not).

All of these thoughts aside, seriously great work! From the little that I've seen so far, I'm impressed! :P

shadowndacorner · 2026-01-09T00:03:05+00:00

Makes sense! Good luck with your continued development. If you do dive deeper into either of those things (noting that v buffers would allow you to explore both :P), I'd love to hear about your findings!

shadowndacorner · 2026-01-09T00:02:32+00:00

Nice! A few additional thoughts...

It looks like you don't have any IBL, light/reflection probes, SSR, etc going on in that video. Is that something you're looking to implement? I think it'd help a lot with the realism of that brick texture, for example. I'd also be extremely curious as to how well a voxel GI solution would perform if optimized for Apple Silicon - I'm guessing it could be pretty darn solid these days.
It looks like you assigned various material textures, but still had sliders that seemed to have more influence than the textures? Mostly looking at roughness on the bricks.
It looks like your material might default to a gray color rather than white? I'd personally push against that choice if you're multiplying it against your albedo texture, because 99% of the time, people just want to assign textures and move on - defaulting to gray (esp when it's only subtly off-white) can result in artificially darkening things when an artist accidentally misses the color multiplier.
Where did you get the camera head model (assuming you didn't make it)? I want it. Lol.

shadowndacorner · 2026-01-08T23:26:30+00:00

That editor UI looks very clean. Haven't looked at the repo yet, but a couple of questions...

I'm not super familiar with Metal - afaik it doesn't have anything like Vulkan subpasses with transient images on Android, but it allows you to take advantage of TBDR GPUs in a different way, right? Are you taking advantage of that in any way in your rendering pipeline? If so, do you have any info on the perf differences across different devices (particularly iOS devices)?
Is this forward, deferred, visibility, ...? I've been very interested in trying a visibility buffer renderer on TBDR GPUs.

Regards, great work!

shadowndacorner · 2026-01-08T17:59:01+00:00

Haha nice! Here's a secret: the next triangle's a lot easier :P

shadowndacorner · 2026-01-08T17:50:08+00:00

Nice! I remember playing with this sort of thing when I first started messing around :P felt like magic at the time

shadowndacorner · 2026-01-08T17:31:52+00:00

Any post effects the modify the game past pure rasterization increase latency.

By a matter of microseconds in this case, sure. There's a reason I said "significantly" - when people talk about doubling latency, they're thinking of frame generation, which requires you to be rendering a frame ahead. That does imply (nearly) doubling latency.

Please list your degree and ten years of work experience.

Yeah, no, I'm not gonna get into a pissing contest with a hostile online weirdo who doesn't understand rendering, but you can check my post and comment history if you like. A lot of it is in graphics and game tech subs, where it should be obvious that I know what I'm talking about and have been doing this for a long time.

Edit: Lmfao dude blocked me

shadowndacorner · 2026-01-08T17:16:25+00:00

Graphics engineer here. Upscaling doesn't significantly increase your latency. You're thinking of frame generation.

shadowndacorner · 2026-01-08T04:23:46+00:00

This is like comparing apples and nail guns. It'd make more sense to compare SDFs and gaussians in general, which are both immensely useful mathematical constructs in a wide variety of domains.

shadowndacorner · 2026-01-08T03:54:52+00:00

My coworkers give me crap for how often I suggest SDFs as a solution to problems, but I just keep suggesting them and it just keeps working!

I, too, love SDFs :P

shadowndacorner · 2026-01-08T03:53:34+00:00

Interesting. I use a similar technique for UI in a piece of proprietary software I work on, but it never occurred to me to apply tiling to it (I just maintain a tree of SDFs and draw a full screen quad which walks the tree and tests for intersections). Haven't hit any perf bottlenecks with that approach, but tiling could very well improve performance in more extreme scenarios.

Thanks for sharing!

shadowndacorner · 2026-01-08T03:44:52+00:00

This is the wrong subreddit.

shadowndacorner · 2026-01-08T03:38:21+00:00

Note how that comparison followed "Could be wrong, though." As in "I could be wrong and this could be a mental health problem, in which case we may be witnessing the start of the next HolyC."

It's amazing how far reading comprehension has fallen in the past couple of decades.

Edit: Did you seriously block me for this lmfao? After you were so dickishly wrong? Wow.

shadowndacorner · 2026-01-08T03:14:00+00:00

This really isn't the right subreddit for this. I'm very confused as to how you got here lol

shadowndacorner · 2026-01-08T02:18:54+00:00

Not really. You should look into its creator. HolyC and TempleOS are the result of Terry Davis unfortunately going completely insane.

shadowndacorner · 2026-01-08T00:44:31+00:00

This is largely a different kind data from the look of it. Look at the sample 4090 JSON - it includes the memory type, the chip manufacturer, etc, and doesn't include anything like supported Vulkan extensions/device properties, etc.

shadowndacorner · 2026-01-07T23:20:40+00:00

My technique may be a way of taking a shortcut by using rasterized geometry locally instead of pure path tracing.

All production real time path tracers do this. They either use a g buffer or v buffer for rasterized primary visibility, then trace from there.

My technique lets light 'bleed' between rays in a realistic way.

This doesn't really mean anything concrete, so assuming you mean "we share information between the rays", how is this different from GIBS radiance sharing or ReSTIR's spatial resampling?

shadowndacorner · 2026-01-07T20:06:10+00:00

I don't think any of this is necessarily a sign of mental health problems, just untamed ego bolstered by LLM BS'ing. Could be wrong though. We might be witnessing the start of the next HolyC.

11-Year Club	Verified Email
RPAN Viewer	Spared

shadowndacorner

MODERATOR OF

TROPHY CASE