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

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...

- 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.

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.

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.

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!

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

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

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!

Comments URL: https://news.ycombinator.com/item?id=44160358

Points: 59

# Comments: 27

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

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.

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.

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.