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.

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