[HN Gopher] Spline Distance Fields
___________________________________________________________________
Spline Distance Fields
Author : ibobev
Score : 105 points
Date : 2025-01-06 15:49 UTC (7 hours ago)
(HTM) web link (zone.dog)
(TXT) w3m dump (zone.dog)
| kvark wrote:
| They developed a content generation tool based on splines, as
| well as a rendering algorithm based on finding the closest
| splines to each point. They are claiming real-time rendering (4k
| at 120hz) on CPU... why not run this on GPU?
| felipellrocha wrote:
| Boy... I hate questions of the form "Why not just". Which, to
| be fair... is not the exact form, but the intent of the
| question.
| qwertox wrote:
| Because you can use tools on the splines. You can't do that on
| the GPU.
| jvanderbot wrote:
| If the claims of real-time use are true, why bother?
| kvark wrote:
| Because it has to go through gpu anyway before it reaches the
| screen, gpu can be more efficient at doing this (better
| battery, etc), and we are wasting time transferring the
| pixels to gpu where the splines would be much more compact.
| kevingadd wrote:
| minor nit: it seems like they're not rasterizing every
| pixel on cpu, instead just generating heightmap values
| instead, which is a lot lower resolution?
|
| and games like Dreams have proven that you can ship world
| class experiences using CPU rasterization. If it's easier
| and it performs good enough, nothing wrong with it.
| dcrazy wrote:
| Run _what_ on the GPU? All of Blender?
| badsectoracula wrote:
| This reminds me when i worked on an open world game ~12 years
| ago. I implemented spline-based "stripes" (think long decals),
| mainly to be used for roads (though could also be used for
| smaller things like blood trails) and i added a button in the
| editor to align the terrain with the stripe with a configurable
| falloff so that it transitions smoothly from the stripe to the
| surrounding terrain - and optionally you could use a (grayscale)
| texture to modulate the falloff so that the transition isn't
| completely smooth.
|
| Next thing i knew, the environment artists had started using
| stripes to sculpt the terrain :-P
| Minor49er wrote:
| You're Bad Sector from the Rome.ro forums (way back when those
| existed), aren't you?
| badsectoracula wrote:
| Yes, that'd be me :-)
| r1chardnl wrote:
| Reminds me of Quake patchDef (Biquadratic Bezier surface patches)
| https://quark.sourceforge.io/infobase/maped.curves.html
| pavlov wrote:
| It's nice to see some real-world graphics programming in a visual
| language.
|
| Node-based environments can be powerful for exploring solutions
| like this, but they don't often make it to Hacker News.
| badsectoracula wrote:
| They can also be quite messy and hard/annoying to follow/parse
| since a lot of screen real estate is used for trivial things.
| For example the first graph wastes 300x250 pixels several times
| for what would be a single character in a text-based language
| (and that's if you ignore the padding between the nodes since
| you could claim that whitespace in a text-based language serves
| the same purpose).
|
| And unlike a text-based language where there is (usually) a
| single flow path going towards a single direction, with
| graphics like the one in the article you have several "flows"
| so your eyes need to move all over the place all the time to
| connect the "bits" in order to figure out what is going on.
|
| Though that last part could probably be solved by using DRAKON
| graphs instead (which can also use less screen space) since
| those have a more strict flow.
|
| IMO graph-based visual languages are nice for very high level
| flows but the moment you need to use more than a couple "dot
| product" or "add values" nodes, it is time to switch to a text-
| based one.
| pavlov wrote:
| I agree that large node graphs get unwieldy and nobody has
| come up with a great solution for that. Macros and
| independently scalable groups and visual annotations can
| help, but it depends on the type of program.
|
| I disagree about the single-direction "1D" nature of textual
| programs being unequivocally a benefit. When there are many
| independent paths that eventually combine, it's easier to see
| the complete flow in a 2D graph. Linear text creates the
| illusion of dependency and order, even if your computation
| doesn't actually have those properties.
|
| Conserving screen space is a double-edged sword. If that were
| the most important thing in programming, we'd all be writing
| APL-style dense one-liners for production. But code
| legibility and reusability is a lot more than just who does
| the most with the least symbols.
| badsectoracula wrote:
| > I disagree about the single-direction "1D" nature of
| textual programs being unequivocally a benefit. When there
| are many independent paths that eventually combine, it's
| easier to see the complete flow in a 2D graph.
|
| This is where having separate functions help - as a bonus
| you can focus on that independent path without the rest
| being a distraction.
|
| If there are _multiple_ independent paths that connect at
| separate points where you can 't isolate them easily if
| they were a function, the graph is already a mess.
|
| > Conserving screen space is a double-edged sword. If that
| were the most important thing in programming, we'd all be
| writing APL-style dense one-liners for production.
|
| That is a bit of an extreme case, it isn't about conserving
| _all_ the screen real estate, just not being overly
| wasteful. After all the most common argument you 'd see
| about -say- Pascal-style syntax is that it is too verbose
| compared to C-like syntax, despite the difference not being
| that great. You'll notice that despite APL-like syntax not
| being very popular, COBOL-like syntax isn't popular either.
|
| You don't have to go to extremes - notice that in my
| comment i never wrote that _all_ uses of graphs should be
| avoided.
| nkrisc wrote:
| I would wager that Blender's geometry nodes are over all a
| net saving in screen real estate when compared to the amount
| of code they abstract away. Sure, in a trivial example they
| seem unnecessarily large, but there are some nodes that do a
| lot of heavy lifting, and are no bigger than any other node.
| Overall a strange metric to track, IMO, unless all your
| variable names are one letter.
| badsectoracula wrote:
| Which is why i wrote that last paragraph: for high level
| stuff with nodes that abstract the heavy lifting they are
| fine. Sometimes you may even need these "add" and "dot
| product" nodes to glue these together. The issue is when
| you start using a lot of "low level" nodes.
|
| Think of it like using a shell script vs something like
| Python: you can do a ton of things in shell scripts and
| write very complex shell scripts, but chances are if a
| shell script is more than a few lines that glue other
| programs together, it'd be better to use Python (or
| something similar) despite both being "scripting"
| languages.
| WillAdams wrote:
| One of my favourites is:
|
| https://github.com/derkork/openscad-graph-editor
|
| though I usually use:
|
| https://www.blockscad3d.com/editor/
| nkrisc wrote:
| There are times when using Blender's shading node graph that
| I'd really just rather be writing GLSL/HLSL. But overall I
| still like it.
|
| Geometry nodes, on the other hand, I think are amazing. They
| really do provide a very useful abstraction over what would be
| _a lot_ of tedious and error-prone boiler plate code.
|
| With just a few nodes I can instances and properly rotate some
| mesh on every face of some other mesh. Boom, done in two
| minutes. And you can do so, so much more, of course.
|
| The obvious downside is in complex scenarios the graph can be
| more difficult to manage and because of the nature of how its
| evaluated there are times you need to think about "capturing"
| attributes (basically a variable to hold an older value of
| something that gets changed later). But nothing is perfect.
___________________________________________________________________
(page generated 2025-01-06 23:00 UTC)