[HN Gopher] Visual Node Graph with ImGui
___________________________________________________________________
Visual Node Graph with ImGui
Author : ibobev
Score : 204 points
Date : 2023-09-29 11:18 UTC (11 hours ago)
(HTM) web link (gboisse.github.io)
(TXT) w3m dump (gboisse.github.io)
| samsquire wrote:
| Looks really good, thank you for sharing.
|
| I enjoy graphs, you can think of the world wide web as a graph.
| When you click a link you get a different perspective of that
| vertice.
|
| My dream is to combine nodal rendering to animated field of view
| layout.
|
| In all the attempts I've seen to create an interactive 3D graph
| the problem was that moving around didn't change the perspective
| and paging in and out of the nodal elements.
|
| Navigating a graph where the graphs aren't moved relevantly while
| you walk around is not useful it's like manual labour of walking
| to the store, the nodes need to change perspective, animate into
| different variations as you move around and page in and out
| different edges and vertices.
|
| The algorithm you use to move/page nodes in and out and around
| has to be dependent on what you're doing.
| smaddox wrote:
| > This felt like a good solution; I could instantly see how most
| features could map to this setup and it most definitely wasn't a
| visual programming system...
|
| Huh? I don't get this. The example right below seems a lot like
| coding with nodes to me. Perhaps they mean it's less procedural,
| more declarative? But that's the case with all of these visual
| programming interfaces. At least until you run into the limits of
| the declarative sub-language.
| pests wrote:
| It sounds like they wanted to avoid programming at the level of
| loops, if statements, functions, blocks, etc which many visual
| node editors do employ. I do agree though that his solution is
| similar to various shader graph editors.
| mrblk wrote:
| reminds me of werkkzeug which was used to produce demos by
| farbrausch back in the days
|
| https://www.pouet.net/prod.php?which=12511
| neoneye2 wrote:
| Explanations of how werkkzeug works
|
| https://youtu.be/P7MNvUz5yyU?si=N1zED81UlYfuAV8N
|
| https://www.youtube.com/watch?v=uUfV41HE_Dg
| mrblk wrote:
| wow, I never saw those videos! thanks for linking
| neoneye2 wrote:
| Immediately after seeing werkkzeug, I started coding my own
| wz clone.
|
| Here is a video of what it was like around 2009.
| https://www.youtube.com/watch?v=ZPYy8lry2do
| Zetobal wrote:
| I like the implementation of litegraph in comfyui they are
| basically just python classes with a bit of mapping.
| terhechte wrote:
| I've been searching for a GPU Node Graph library for some time.
| All my Github Fu failed me. I'd like to have something which
| offers:
|
| - Video
|
| - Images
|
| - Rich Text
|
| - Animations
|
| And a way to compose these blocks together into bigger structures
| with shader effects. Preferably in a compiled language such as
| C++, Rust or Swift. Does something like that exist?
| jcelerier wrote:
| https://ossia.io does some of it, I've been working on a new
| release that also supports the whole QtQuick stack in the node
| graph items but you can already combine videos & shader
| effects. There are also text and image nodes but i want to redo
| them, they were quick and dirty prototypes for an exhibition
| and don't support some of the use cases artists using the
| software then came up with, e.g. sifting through gigabytes of
| images more or less instantly.
|
| The underlying C++ part of this is kiiinda independent of the
| rest of the app, at least the graph part :
| https://github.com/ossia/score/tree/master/src/plugins/score...
| - I'm sure it wouldn't be too hard to extract this folder
| specifically. Shaders use the ISF specification
| (https://isf.video) and the backend is through Qt's RHI so
| things are then mapped to metal, vk, d3d or GL.
| hermitcrab wrote:
| Ossia looks very cool. I have also developed a node-based
| tool in Qt/C++ (https://www.easydatatransform.com/). Might be
| interesting to talk Qt-related stuff with you some time (Qt
| versions, deployment, OSs etc).
| pjmlp wrote:
| The ISF specification is kind of neat, I wasn't aware of it,
| thanks for the hint.
| [deleted]
| ux wrote:
| We've just released a new version of Nope Foundry yesterday:
| https://www.nope-foundry.org
|
| You might want to have a look.
|
| Video, Images, Rich Text and Animations are typically what we
| strive for. Check out maybe
| https://nopefoundry.github.io/nope.gl/usr/howto/renders.html
| and the other howtos.
| s-macke wrote:
| I have experimented with the new WebGPU API a lot and it seems
| this API is predistined for node graph type of programming. I
| am hoping that someone will build a website such as Shadertoy
| [1] and compute.toys [2], but with a node graph editor.
|
| [1] https://www.shadertoy.com/ [2] https://compute.toys/
| hermitcrab wrote:
| In my experience node-based tools work great:
|
| -If they are restricted to a suitable problem domain (e.g.
| image/audio/data processing).
|
| -If have the ability to do some scripting in a node, to cover
| specialzied cases the designer didn't allow for.
|
| (I'm working on a node based data wrangling tool)
| [deleted]
| andybak wrote:
| Off topic (and a bit "hijack someone's post") but I keep thinking
| about the inherent suckiness of visual programming and what needs
| to happen to improve it.
|
| I think the core problem is that - unlike text-based programming
| - the editor is intimitely tied to the rest of the authoring
| environment and runtime. Sometimes it _is_ the entire authoring
| environment.
|
| Text coding benefits from standardised tools that are decoupled
| from the applications they serve and interoperability. You want
| to write your Rust in nano? Go right ahead? Want to write some
| lua that does bulk edits to your COBOL library. Fab.
|
| More importantly is that we learn the tools and keyboard
| shortcuts and those skills transfer to new languages and
| environments.
|
| The main issues would be mitigated by:
|
| a) some standardized UI conventions
|
| b) all visual programming tools offering lossless round-tripping
| to textual representation (it doesn't have to be tuned for human
| writability - it just needs to be sane)
|
| B also helps with the other big flaw with visual programming -
| the way it breaks version control workflows. I heard from an
| Unreal dev that even opening a blueprint and highlighting a
| different node will change the file. That must be fun when it
| comes time to merge...
|
| I could write reams on this topic. I _want_ visual programming to
| be better - I think it has unique strengths. But currently it has
| two niches:
|
| 1. People that can't bring themselves to learn text-based coding.
|
| 2. Tasks where discoverability and immediacy trump all the
| disadvantages.
| [deleted]
| mschaef wrote:
| > Off topic (and a bit "hijack someone's post") but I keep
| thinking about the inherent suckiness of visual programming and
| what needs to happen to improve it.
|
| Visual programming presents huge challenges.
|
| > Text coding benefits from standardised tools
|
| That's the biggest, IMO. Some degree of text processing is
| essentially universal to computing after the early 1950's. As
| you mention, that provides a huge amount of prior art in
| editors, source code control systems, various kinds of
| messaging, display tools... the list goes on and on. Textual
| languages can natively reuse all of this. Graphical languages
| need some sort of mapping to text in order to use tools that do
| not quite fit the way they work.
|
| The other challenge is the way visual programming complicates
| the mechanics of the job. Laying source out in (~) one
| dimension is hard, laying it out in two dimensions is harder.
| Naming a function is hard, drawing a representative icon for a
| function is harder.
|
| You also lose the notion of linear ordering when you move from
| a list of statements to a 2D graph of nodes. This is useful
| when you're modeling a data flow graph or a state machine, but
| harder when you want to express a branch or a loop.
| [deleted]
| Buttons840 wrote:
| I think the inherent suckiness with visual programming is...
|
| Imagine I was a consultant who offered to sit and watch over
| your shoulder and comment _only_ on syntax issues. If you make
| a syntax mistake, I will help you fix it; "you need a closing
| paren here". I will also offer syntax tips constantly while you
| work; "looks like your going to create a list, first choose
| what you want the first item in the list to be". You should
| expect to be a little slower in exchange for these
| consultations I offer. Would you hire me?
|
| These are essentially the tradeoffs offered by visual
| programming. Slower work for syntax level help. And visual
| languages often have some premium cost to them.
|
| People doing significant programming don't need syntax level
| help.
| dadadad100 wrote:
| A long time ago I worked at a company trying to commercialize
| a visual programming framework for general use. And before
| that I was on a team that built a visual programming
| environment to define simulation models for the largest
| flight/other simulation company in the world.
|
| What I learned was that when a problem domain needed a visual
| representation they had already created it (using pencil and
| paper, decades ago). Think of schematic diagrams, piping and
| instrumentation diagrams and such. In those cases we were
| very successful. In cases where no such diagrams exist, we
| always failed to create one that stuck with the users. Text
| is great for code because is is extremely compact and takes
| advantage of things like visual rhyme. Uml, for example, can
| never achieve the same results
| jkcxn wrote:
| It's not syntax help thats useful about visual programming
| it's the 2-way communication between the programmer and the
| running program, and also being able to refer to other parts
| of a program spatially rather than by a name.
|
| Most kinds of software don't need these things but if you're
| writing code that generates graphics or audio signals then
| you do, because you get to manipulate your program and
| see/hear effects in real-time, and also seeing how different
| parts of your program connects together is more important
| than giving names to them (where there may not be a useful
| name you can give them anyway)
|
| Theoretically you might be able achieve these things with
| only a textual representation and it could be best of both
| worlds
| SanderNL wrote:
| How is this different from "drawing is better than writing a
| book"?
|
| Some people write, others draw. Each method has its own
| strength and problem spaces.
|
| Encoding a complex issue sometimes is just shitty with a visual
| metaphor. Other times writing code is a really bad idea. If you
| want to express "flow" or "connections", filter or stream
| systems like modular synths, that's when the visual metaphor
| shines.
|
| You use whatever metaphor works best at the moment. One cannot
| replace the other.
|
| The "problem" is that people want to push all of "programming"
| into the visual metaphor. That's like pushing all of
| programming into only functional, only declarative, only
| imperative or only OOP (or whatever), but worse. That's not
| going to work, but I guess people can try.
| hermitcrab wrote:
| Yes, attempting to re-implement generic programming (as
| opposed to a particular domain) as node-based seems doomed to
| failure.
| steve_adams_86 wrote:
| I agree. I love modelling state machines in node-based
| systems, and I think user interfaces could be fine in node-
| based editors (I've never tried, but they're already node-
| based internally and they seem well-suited in the same way
| state machines are). But I'd hate to model something like a
| flow of concurrent tasks with retries and exponential back
| offs or something where the visual queues don't seem like
| they'd be obvious and the editor couldn't (as far as I can
| imagine) offer useful simulation or testing tools.
|
| It could be a failure of my imagination. I've designed
| similar things though, and these weird cases (especially
| temporal cases) become extremely hard to represent more
| universally. I suppose you could offer a "timeline" to
| indicate how things would behave on a time scale, but even
| that... I just don't know.
|
| It also seems key to have a node-based editor work with one
| language or a set which map together extremely well.
| hoc wrote:
| OTOH, whenever somebody is explaining their multithreaded
| async code lines on a web page or in a book, there a
| graph is shown, since it seems to be the ideal metaphor.
| Just not for implementation purposes...?
|
| There's definitively some hard limitation in dimension,
| though, so there might be the idea that, if one can only
| show problems of a certain limited complexity visually,
| why not do all the lousy (text-based,
| relational/reference-based way) but universal way that at
| least can be stored and edited everywhere.
|
| So a central question might be: can we have a universal
| gain from, let's say, a three dimensional notation that
| still does not limit the problem space to these
| dimension.
| hermitcrab wrote:
| I think node-based can work well for data flow or control
| flow. But probably not both.
| fiddlerwoaroof wrote:
| We already have had good UI designers, they just never
| made it to the web.
| steve_adams_86 wrote:
| As a UI designer (at times), I have to say... It isn't
| easy. I've made much nicer UIs on MacOS and iOS than I
| have on the web, with considerably less effort.
|
| Part of it is what people expect. You get pushed and
| pulled when it comes to designing things for the web.
| Partially by constraints, partially by people's desires
| and expectations. It's better than ever these days, but
| my career has generally had the greatest challenges
| presented on the frontend of web projects.
|
| I find backend development a bit "smoother". I won't say
| easier, but... I don't know, the frontend of the web is a
| jungle and a bit of an uphill battle sometimes.
| flir wrote:
| Idle thought: I sometimes wonder if SQL could be
| implemented visually. It's basically sets, after all.
|
| I suspect it would quickly become too complex, but there's
| plenty of people smarter than me...
| hermitcrab wrote:
| You often see SQL joins represented with Venn diagram,
| but it realy isn't a great representation of join.
| flir wrote:
| You sure? I tend to think in terms roughly like this when
| I'm selecting a JOIN:
| https://dk81.github.io/dkmathstats_site/set-theory-
| sql.html
|
| Eg (A LEFT JOIN B) = (A [?] B) + A
|
| Maybe I'm missing something though.
| hermitcrab wrote:
| https://blog.jooq.org/say-no-to-venn-diagrams-when-
| explainin...
| flir wrote:
| Hmm. It's true, the set model breaks down when you remove
| the key relationship, or add filters.
| tgv wrote:
| > I think the core problem is that - unlike text-based
| programming - the editor is intimitely tied to the rest of the
| authoring environment and runtime.
|
| Does not sound like the core problem to me. Computers used to
| be like that: everything was tied to the OS and compiler. That
| didn't stop banks from developing pretty complex systems.
|
| IMO, the problem is that visual programming, despite its name,
| is visually a mess. You can't read it, you can't orient
| yourself in it. It's not structured, for starters. And piping
| an input through a sin function takes up 10 times the screen
| space of Math.sin(x), especially if you then have to keep that
| node's output from overlapping other parts. And you always must
| search back where the input to a node comes from, whereas in
| textual programs, you can put that information in the variable
| name. It's just not suitable to our way of thinking in chunks.
| pjmlp wrote:
| That is the outcome of people coding in visual languages like
| BASIC, instead of making use of the structure programming
| tooling, that they also offer.
| dist-epoch wrote:
| We need a generic "graph editor" (let's say VS Graph) and then
| use-case specific "graph server protocols" (Unreal Blueprint
| GSP).
|
| A graph editor is a large undertaking, having a few generic
| ones would avoid so much duplicate work. Having a generic graph
| editor would also allow an extension system to develop around
| it.
|
| Each application would just need to implement the specific
| server protocol which does game rendering etc...
| dleeftink wrote:
| Although it's not quite the same, I do like what Enso[0] is
| bringing to the table, especially the 1:1 visual node/language
| interop. Whether this is generalisable to a fully decoupled
| interface remains to be seen, but there's definitely potential.
|
| [0]: https://enso.org/
| hoc wrote:
| Well, for a node oriented approach we could have standard auto
| layouting that we could augment with hints for grouping,
| layouting prioritization etc. to achieve some kind of
| "universal editing" approach for visual programming.
|
| After all, we use lots of comments to give some structure to
| text-based coding.
|
| There was a post about https://github.com/samuelmtimbo/unit
| recently, which at least uses some kind of hinted auto-layout
| (besides the more propriety fancy)
|
| I really want to see more graphical coding for years, but
| node/graph-based and blockly seem to be the only approaches
| that got sone traction so far. So I like this thread and it
| seems at the right place.
|
| I'd wish to see more use of 2D and now 3D space for
| structuring, annotation and overall overview and navigation.
| Text plus a directory tree view can't be everything, especially
| since we have so many structural views for coding, runtime,
| versioning that basically are connected in our mind, but also
| could be in a space with more dimensions. Not sure if we could
| find/agree on a common denominator, though. Text is one because
| it's basically the bottom of common ground. Not sure if that's
| not just the trivial solution (ok, I am).
| WillAdams wrote:
| The problem here is that a fundamental question has not been
| answered, and as far as I can tell, has not been addressed by
| any of these visual environments:
|
| What does an algorithm look like?
|
| Herman Hesse alluded to this in his novel _The Glass Bead
| Game_, but despite decades of discussion and work, no one has
| made a convincing pysical representation of that system.
|
| I love the concept, and have made some moderately complex
| attempts, e.g.,:
|
| https://www.blockscad3d.com/community/projects/1430644
|
| https://github.com/WillAdams/gcodepreview
|
| it always devolves to screen size being out-paced by problem
| complexity --- one gets something of an inkling of this at:
|
| https://scriptsofanotherdimension.tumblr.com/
|
| Alternately, one can just break a project down into modules,
| but then the top-level view becomes the wall of text
| representation (albeit w/ nice lines or captured into pretty
| boxes) which one is ostensibly trying to escape.
|
| I'd love to see someone succeed in this, and I've been using:
|
| https://github.com/derkork/openscad-graph-editor
|
| quite a bit, and put a bit of money towards:
|
| http://nodezator.com/
| Keyframe wrote:
| CGI has used "visual programming" for decades not with great
| success. Quotes there because it depends on what you consider
| visual programming. It's not syntax level minutia as it's more
| of a functional blocks or expressions even that mutate data
| from start to end.. which in its essence programming is all
| about anyways. See Autodesk Flame, Digital Foundry Nuke, SideFX
| Houdini for examples.
| vidarh wrote:
| I worked on a visual language design for a long time as a
| hobby, and the biggest problem, I think, is _how you
| communicate about the code_.
|
| Imagine asking Stackoverflow about a coding problem that
| involves a visual node structure and code attached to some of
| them.
|
| So yes, the round tripping is essential, but it also needs
| people to understand and be able to talk about the code in its
| textual form.
|
| I came to the conclusion that realistically these tools will
| always be severely limited unless they focus on being good
| automated visualisation tools of syntax that is text first.
|
| I'd like to be wrong about that, by the way.
| devmor wrote:
| Every time someone tries to standardize UI, we end up with XML
| again. There's gotta be something else.
| hermitcrab wrote:
| You've go to store your graph in some structured form.
| Ideally text based. XML seems as good (or bad) a format for
| this as any other.
| TeMPOraL wrote:
| Could be XML, could be SQLite tables, it really shouldn't
| matter - the format would not be meant for human
| consumption, much less editing by hand. It would best be
| diffable, yes, but not necessarily by diff(1).
| 35mm wrote:
| Is there something like this for the web?
|
| I have a Django app for building topical maps for content
| marketing, and I'd like to be able to visualise the topic maps in
| terms of interconnected nodes.
| artificial wrote:
| Several out there. Pick your poison https://vueflow.dev/ or
| https://reactflow.dev/
| _0ffh wrote:
| I wish there was a nice, light-weight library like this for
| creating node-graph editors in Javascript.
| robterrell wrote:
| Have you seen https://github.com/jagenjo/litegraph.js ?
| _0ffh wrote:
| Not yet, but I'll have a look, thanks!
|
| I'd need it to work well with touch, for phone or pad users.
| d--b wrote:
| To all Visual Node Graph editor developers, I have a request: Can
| you guys make nodes snap to a grid?
|
| This would make graphs a lot cleaner AND could be made browsable
| by keyboard.
| [deleted]
| VladimirGolovin wrote:
| In Ultraforge (https://filterforge.com/ultraforge/), all nodes
| will snap to grid, and the nodes are designed in such a way
| that connections between then will automatically go along the
| grid lines -- this greatly reduces the clutter.
|
| Could you explain, however, how could the grid make node graphs
| browsable by keyboard?
| d--b wrote:
| Let's say your grid is 8x8, you could make a pointer that's
| 16x16 and that you can move around with the arrow keys. When
| it touches a node, then the node is selected. But then you
| can hold ctrl to jump from one node to another, if they're
| aligned.
|
| Kind of like excel, how you browse multiple tables in the
| same grid.
| hoc wrote:
| I'd think that also helps in a lot of pointer-based editing use
| cases: Creation, selection, grouping/clustering, sorting,
| transforms...
| catapart wrote:
| Yay! More work on, and thought put into, visual scripting
| systems!
|
| This looks really great! I'm not sure I agree with the
| conclusions, nor the need for a different system than what
| Blueprints or Geometry Nodes offer. Personally, I think both of
| those things are great save for the major (and infinitely
| complex) feature of "clean this board up". The nature of the
| graphs make it easy to see when code repeats or is doing too
| much, just so long as the graph, itself, is legible. So if you
| could have some smart snapping, to force devs to keep it tight,
| or if you could employ some kind of machine learning for cleaning
| it up into sensible data flows, I think most of the biggest
| complaints I've heard from people who actually use these systems,
| would be addressed.
|
| That aside, I'm always open to a new way! I, again, don't think
| what was demo'd is any cleaner than Blueprints (especially not
| fond of all of those connection points. Bottom and top
| connections don't look tidy), but that is definitely in the eye
| of the beholder, and this appears to be a well-delivered first
| attempt, but a first attempt nonetheless, so I'll assume that
| whatever visual issues I have with it, the underlying scheme
| works well. Because, honestly, it looks like it does! As
| presented, I think the system would definitely work great and it
| would certainly make a few things easier than how they're handled
| elsewhere. I'll admit, 'curry it to a specific data type and then
| operate on that' is how I code anyway, so I'm biased toward
| liking it. But I like that methodology because I think it works
| exceptionally well, especially for work like rendering. So great
| work on both the full app and this whole new way of scripting!
| hermitcrab wrote:
| > or if you could employ some kind of machine learning
|
| I'm not sure machine learning is appropriate for graph layout.
| What a good graph looks like is already well known: no
| overlapping nodes, minimum line crosses, not too much 'white
| space'. But doing this layout automatically is very hard (NP
| complete?).
| catapart wrote:
| Sorry if I was unclear: I just meant that we could employ
| tensor-based learning methodology, like ChatGPT uses, to
| parse the graph representations and understand not only their
| visual layout (ex: no lines crossing), but also their
| contexts (ex: group functions that all emit events near each
| other on the graph). Having a machine be able to know what
| you're trying to do and then clean it up to based on that
| would be great. Even better, if it could learn how you tend
| to organize things and pick up "configurations" from that.
| Adding in "reroute nodes" and stuff when things start looking
| too loose for your personal liking, or whatever.
| hermitcrab wrote:
| Wouldn't that need an awful lot of training data? And
| different people might have very approaches to laying out a
| graph, so all that training data would need to come from
| one person, wouldn't it?
| catapart wrote:
| Oh, for sure! It would need to be trained on the
| 'default' way of doing things, just like a linter has a
| default config. THEN it would need to train on how you
| code (pin ordering, reroute node layouts, loop layouts,
| etc), the entire time you work with it. And, of course,
| in order to train, you would need to be able to tell it
| "hey, don't do that; I know I did it here but don't mimic
| that" as well as "mimic this, every single time. Don't
| use the defaults". Those explicit commands are extremely
| important for handling the edge casing (similar to
| newline vs inline brace openings).
|
| But, honestly, that kind of thing is the only valuable
| future for AI that I see, as a creative. I don't need it
| to write my code for me, but I could sure as hell use it
| to handle all the tedious bullshit that we've cobbled
| together as far as tooling, CI, formatting and any other
| "had to do it this way to make machines understand it"
| half-measure we've had to take in the past century. The
| AIs that we see, now, which learn from a huge dataset and
| then stay mostly inert until the next big update are more
| toy-like in my figuring. They are standards to measure
| against and proofs of all kinds of very interesting and
| useful concepts. But the lasting/useful AIs will be the
| ones that train alongside your work and ONLY on your work
| (or, let's face it, the work done in your company that
| will be shared amongst all corporate employees so that
| all work can be done more efficiently) in order to
| provide you with what you would be trying to do anyway.
| CyberDildonics wrote:
| This doesn't make any sense. There are already lots of
| graph UIs that can auto layout. Why would you need 'tensor-
| based learning' to uncross lines?
| xuhu wrote:
| Aligning related nodes regardless of the arcs between them is
| a big plus, and if ML can infer that automatically from case
| to case, it's probably worth considering using it for layout.
| pjmlp wrote:
| Looks quite nice, thanks for sharing and the overview of the
| approach taken.
|
| As remark on the spaghetti coding, most visual programming
| languages do offer modules, and the ability to add some structure
| similar to digital circuit design, if anything they make it
| easier to visualize bad code when proper coding isn't followed
| upon.
| frou_dh wrote:
| Here's a good comment from the archives elaborating on that:
| https://news.ycombinator.com/item?id=4515315
| pjmlp wrote:
| Yeah quite to the point.
| bluepanda1234 wrote:
| What library did you use to create the node graph?
| https://github.com/Nelarius/imnodes?
| joenot443 wrote:
| Looks more like https://github.com/thedmd/imgui-node-editor/ to
| me - both are great libraries though.
| artemonster wrote:
| On the topic of this, hey HN, would you play a factorio-like game
| that ditches all belts and trains and just looks like UE
| blueprint from hell (i.e. like this
| https://blueprintsfromhell.tumblr.com/image/185614874046)? So
| abstract item-producing nodes that can be moved around freely and
| are connected via some logistic network? Thanks for feedback!
| rossant wrote:
| ImGui is an amazing piece of software. Being able to quickly
| display interactive widgets and dynamic charts for your variables
| and objects is incredibly useful when working on GPU-based
| visualization applications. The variety of features it offers is
| truly impressive.
| klaussilveira wrote:
| imgui is such a breath of fresh air. I started using it for my
| game prototypes and engine work, but quickly spread to anywhere I
| might need a quick cross platform GUI. You can see it everywhere
| now in the game industry. Pretty much every screenshot that leaks
| from major studios has imgui on it. It just works.
|
| Kudos to Omar, the author of imgui: https://github.com/ocornut
| [deleted]
___________________________________________________________________
(page generated 2023-09-29 23:00 UTC)