joeld42

I think this approach (separate parts) is the right call. This is how human artists build models, and once the model is built and segmented you can decide which parts go together, and then then group, remesh, UV-map and bake those parts. All of which are hard problems too but are getting closer to being automated.

Yep. I was an intern at Disney Feature Animation when GIMP first came out. It was really exciting, an alternative to Photoshop (which used to run on linux!) and our in-house painting tools. I pushed for artists to use it, but was told by management to stop mentioning it as "Disney could never use a tool called GIMP". Also that reaction from several artists (who were already tech-savvy, linux using folks in the exact target audience) so it wasn't just "corporate". TBH I think a lot of programmers do this intentionally to protect themselves from their little project ever becoming too mainstream.

Take a look at Slint or Avalonia if you miss this experience.

And I'll take needing an internet connection over having to install Visual Basic from a stack of CDs.

I'm still not great at it, but the biggest thing that helped me was to give myself a rule, "Don't talk about what I'm planning, only talk about what I've done". Explaining a project's vision or goals give my brain a mini-version of the feeling of accomplishment of actually doing it, and I found that I would use that as a replacement for actually building stuff (which is much more work). Instead, if I only talk about the parts that I've completed, it's very motivating to build the next step so that I can share it. It also gave me more flexibility to change course during a project.

Some Jam Games with web builds:

https://itch.io/jam/luxe/entries?ref=luxeengine.com

https://ldjam.com/events/ludum-dare/56/terrarium-combinarium

https://joeld42.itch.io/bridges

More jam games that I didn't make a web build for but downloads are available:

https://joeld42.itch.io/lighthouse-keeper

https://ldjam.com/events/ludum-dare/54/cargo-space

https://ldjam.com/events/ludum-dare/53/last-mile

https://ldjam.com/events/ludum-dare/51/artichoke-key

On Steam:

https://store.steampowered.com/app/1836400/Mossfield_Origins...

I've been playing with this engine for a while. I really like the engine. For me the best features are:

- Scripting is really ergonomic, and fairly fast performance-wise. And if you need something to be really fast writing native extension modules for wren is pretty straightforward. So it's a choice between "reasonable" perf scripting and "fast" native code, which is much better than something like Unity where everything is kind of in the middle.

- Wren fibers (a form of cooperative threading) are fantastic for dealing with game logic (NPC state, game AI, etc) without introducing the complexity of true multithreading.

- The graphics/render module is extremely configurable. The whole render module is just a script that sets up a fast c++ execution graph, and you can modify/script this.

- The tools are very nice and a lot of care put into them. I don't use the editor too much, and mostly interact through code, but for things like level design it's really nice to have.

- Many game engines feel like a good fit for a large project or a small one but not both. Luxe is great for small jam games and full-sized projects. A project can be pretty much just a project file, a few configs and a script, or a large structure and the editor encourages (but doesn't enforce) a good project layout.

- Drawing is super flexible. You've got sprites and shapes and meshes and tiles and everything, but there's also an "immediate style" drawing api that is very high quality. Similar to having "Shapes" extension in unity but it's a first class citizen and built in.

- The "Modifiers" (which is Luxe's ECS-like component thing) took me a while to get used to using, and can be a source of friction at first, but once I got it it really feels like a better way to do things. And it's entirely optional so you don't have to if you're still learning.

- Outside of code and raw assets like images and mesh, almost everything is stored in ".lx" files which are very json-like, which can be really helpful for debugging and understanding what's going on, and on many occasions I've been able to automate stuff from script just by writing out or modifying lx files.

- Features and fixes are added constantly, but done carefully in a way that doesn't break existing code too often or without a clear migration strategy (glares at bevy).

It feels like an engine built for small teams and experimental workflows. Especially if you're looking for alternatives to Unity, I'd recommend it.

hmm, i've played around a bit with level design in the past and honestly Arcol wouldn't be that great a fit. I like Probuilder in Unity for that, I think the key to any good workflow is immediate changes and fast iteration, so you really want something that's pretty tightly integrated into your game engine.

It could be useful for greyboxing or even just generating some rough shapes though. We do export GLTF which is easy to get into game engines.

yeah, great idea. Eventually we'd love to get there, supporting all stages of the AEC pipeline. But the scope is so huge we can't give it the level of design attention and polish that we want if we try to do everything, so we're focused on feasibility for now and try and make a great experience for that.

Exactly! It’s great to see that this idea resonates!

We're hoping to provide tools that let firms build whatever workflows they need.

Right now, we have design options to present and compare different options and variants of scenes, and boards and comments, but we don't enforce any workflow.

Looking at how customers use these features and adding tools to enable this is definitely a big focus in the near term.

It coexists with Revit right now, and is a good place to do feasibility and early design and get instant metrics and feedback. We think it's a lot more collaborative and design friendly.

One day we'd love to take them on directly, I think there's a lot of architects out there looking for something better.

As far as collaboration features, we've built it from the ground up with collaboration in mind, so you can work with other users directly in the same scene and see their actions and updates. We've got collaborative presentation boards with views and metrics that can update live, and of course workflow features like commenting. And since it's browser based, there's not the friction of installing a desktop app, which can be significant at some orgs.

We'd love to know what you think though, give it a try and let us know what collaboration features you'd use!

Thanks! We love to hear it!

Exactly, at this stage, the output is mainly for feasibility, presentations and communication. But we can also export models to Revit or 3D formats like GLTF to use in the next steps of the process, or for renders, etc. But we're planning to continue to add features to make it useful further down the AEC pipelines.

Good point about the play button, I'll pass that feedback along. :)

We don't need to update the scene at once, so when geometry changes we rebuild the buffer and send it over to typescript, and the three.js mesh will own the buffer. By being careful about what needs to be updated, we can keep things interactive.

This is an older blog post but it covers the general idea of it: https://blog.arcol.io/parametric-geometry-engine

haha yeah! It feels like a real pain point in the industry right now. Hopefully we can make it easier for communication between design, engineering and construction.

It is using ThreeJS for the 3D rendering, with a custom Rust geometry kernel to generate the mesh buffers to render. The editor interface is React based.

We're launching Arcol today! Check it out. Modern CAD tool, built for the browser with Rust+Typescript for high performance and an elegant UX.

Check out the announce video that explains some of the ideas behind it: https://www.linkedin.com/posts/paul-o-carroll-38aaa1105_arco...

Feel free to post any questions and I'll do my best to answer!

The one that had the most personal influence on me was the chapter from Michael Abrash's Graphics Programming Black Book: https://www.phatcode.net/res/224/files/html/ch17/17-01.html#...

CPU are very different these days, but the process he goes through is essentially unchanged.

If you are looking for an existing car, there's a lot of sites selling pre-made vehicle models for pretty much anything, that's probably going to be higher quality and need less cleanup than anything you can get from scanning.

One of the problems you'll have is photoscanning does not do well with shiny surfaces, as the highlights move and confuse the reconstruction. If this were a model or maquette or something, they would probably spray paint it matte before scanning, which I doubt you want to do with a real car.

If you need high quality, honestly I'd just hire a hard surface modeller. There are people out there who make cars all day every day. If you just need low quality, Unreal's RealityScan app, Polycam, or AliceVision are good places to start.

Most of the drawing work of a GUI is drawing text, shape paths, and images. A GPU-accelerated UI layer draws these using GPU commands. It's not exactly the same as making an ortho 2D scene, but conceptually that's pretty much it. Often it means using crude geometry (such as a quad per glyph in a text renderer, or a "ribbon" of quads to cover a curve) and using a shader to draw the glyph or curve itself.

For a simple example, think of a rounded rect. Typically this would draw as a quad (a pair of triangles), and a shader would calculate the rounded corners.

There's also a lot of compositing and clipping that happens in a UI (e.g. a large widget inside a scrollbox) which is challenging to do on GPU as these get nested.

ImGui doesn't have "components" like a traditional toolkit. If you want a custom component you just make a regular function like:

MyCustomThing::MyWidget( "name", whatever_value );

And it gets the current rectangle from a global context, can allocate some of that rectangle space for itself, draw things, react to events, etc. It's more complicated when the widget needs to store state, but ImGui has pretty well established conventions for how to do that, which basically boils down to hashing the widget name or ID and storing your state there. And when you try, you find you need a lot less state than you might expect. Of course if you have custom data that already has state (e.g. an object passed into your widget), you can use and modify that directly which is great.

It's a very different way of thinking, and it does have some challenges but it usually ends up being a lot simpler and more robust than a "retained mode" gui.

This looks really good. It's nice to see some options like this (and slint) appearing for cross-platform desktop GUI. I'm pretty skeptical of "modern" c++ but this looks like a good example of using it where it makes sense.

The data binding looks particularly clever. That's usually the Achilles heel of GUI toolkits (for me at least) and that looks like a clever and novel solution if it works.

It's a gambling term, it means the amount you have to win to break even.

I've heard of using "Geiger counter allocators" -- custom allocators that make a small click whenever an allocation happens to get a sense of when a program is doing lots of allocations, especially lots of small allocs, as it's running.

I like the idea but this is non-standard enough to be just as hard as making a custom format.

In my experience, the best way to handle this is:

1) Use TSV (tab-separated) instead of CSV (most things that export CSV also export TSV). Strip LF characters while reading and assume newlines are CR.

2) If you have a stubborn data source that insists on CSV, convert it to TSV in a pre-process. This could be a separate step or part of your reader as you're reading in the file. That means there's a single place to handle the escaping nonsense, and you can tailor that to each data source.

Blender Geometry nodes supports SDF modelling. It's just not a widely known or used technique. But it's super powerful.

This jitteryness is because the sample doesn't have antialiasing enabled (since it's pixel art) and the background scrolling is 0.1pixels per frame, which means every 10 frames it snaps 1 pixel. The scrolling is also updating on fixed amount per frame instead of looking at deltaTime, so if there are lags or small differences in frame time this might look choppy.

But I think it's more meant to demonstrate drawing parallax layers rather than subpixel scrolling.

Try contract work. There's a lot of "downtime" where you're looking for contract work that you can work on side projects and as your project picks up you can adjust the amount of contracting to fill the gaps.