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