Low Poly Car Generator

@Erich_L @packrat Thanks guys! Glad you've been enticed to ogle the gif for prolonged periods of time

I've now added parameters to control two chamfers that go all along the length of the body (top and bottom). They refine the form somewhat, make it less raw/boxy. The parameters control chamfers' overall width and angle. The top chamfer's width/angle can additionally vary in front and back. It works like a variable radius fillet but only consisting of one step:

I've also taken this potato-on-wheels on a test drive. No sure how it handles the bends though.

SuperDoomKing Damn, that's some impressive work. Gives me that f-zero vibes, but with wheels. Wish I could make something half as amazing.

Thanks! F-zero vibe is close to what I'm aiming for.

Erich_L In 3.x at least it could. I think you went about it the correct way tho. +

Right. Much cleaner this way and I know exactly what's in the mesh. I suspect CSG could produce artifacts, visible or not, for example when consecutive operands' faces or edges coincide. It'd certainly make more mesh data for the same look. Plus I like this self-imposed limitation of reducing everything to the same topology. Prevents me from piling more and more stuff on.

Ok. I implemented a small management system for storing/retrieving parameters to/from resource files. There's currently about 30 parameters. That's quite a lot given that they control only about 40 vertices (on one side). I was aiming to have as few of them as possible but it's a balancing act. More parameters mean more variety but also les predictability and more chaos/clashing. This will be somewhat boring but I'll just list them all out. Names are a bit ad hoc:

• overall dimensions:
  • base, width, height, length
• cabin dimensions/positioning/shape:
  • cabin_start, cabin_end, cabin_height, mid_cabin_x, mid_cabin_y
  • roof_inset_side, roof_inset_front, roof_inset_back
• chamfers:
  • door_chamfer_w, door_chamfer_angle, bottom_chamfer_w, bottom_chamfer_angle
  • front_chamfer_w, front_chamfer_rot, back_chamfer_w, back_chamfer_rot
• front shape:
  • front_drop, front_inset
• back shape:
  • back_drop, back_inset, back_elev, back_lift, roof_back_in
• wheels:
  • wheel_radius, wheel_thickness, spoke_size, wheel_pos_front, wheel_pos_back
• colors:
  • color_body, color_windows, color_tire, color_spoke

Ugh. There'll probably be a few more.

I manually made some designs. System can now apply parameters from resource files. Just for showoff they are gradually morphed over the existing situation. Note that this is not vertex blending (though it'd be possible because of unified topology), but rather the parameter blending. There's also a subtle shake added to the wheels to fake the rotation. Not sure this is visible on the gif tho

Now the remaining big thing to figure out is how to do randomization. A small GAN style neural net would be ideal for this. Since we don't have those in Godot (yet ), it'll have to be something algorithmic.

Gowydot I love this! I want to learn to do something like this in the future. How many lines of code if to just change from one car to another?

Thanks. Glad you like it. There's not much code. This is more of an exercise in polygonal modeling. Granted done procedurally via code but most of the time was spent on figuring out optimal topology and logical parameters to mold it. The main script is about 800 lines. Half of it is trivial: parameter declarations, getters/setters and functions that assign parameters from/to resources objects. Mesh generation itself is about 150 lines, and blending function is just 15 lines. It goes through a list of parameters and launches a bunch of tweens.

Megalomaniak Now, if you don't mind a 'challenge' to test your system I challenge you to replicate a facsimile of the tesla cybertruck. I don't think it's too outrageous and is already in the ballpark of the previous car example you showed tho. But it would allow you to claim ability to replicate a 'real' car.

Careful there calling the cybertruck a real car... oh wait, 'real' was in quotes... ok then
Here's the best I could pull off:

With this cabin shape, I couldn't preserve a straight line under the cabin going along the whole length of the body. Adding a parameter that "closes" the back side window would make this possible. This parameter would also be useful for all bodies with thick C-pillars (like 70s Firebirds or Vector W8) as well as semi trucks and windowless vans. W8 was, btw, one of my benchmark shapes. Didn't get to making it yet though.

Megalomaniak It definitely can, in the godot 4 thread I shared a Cornell box I had made with CSG that did run into it. Fix was simple enough, I just changed the parenting order around a bit which forced a rebuild, but yes, it definitely can.

cybereality The CSG in Godot is very basic and only useful for prototyping, For example, it doesn't even support UV or textures.

CSG as such is cool but it produces untidy meshes, simply by the nature of the technique. It's ok for making a single design that can be cleaned up offline. But for real time generation of hundreds of live models, I don't know... too risky. I'd choose it for building complex concave shapes. But car body is almost a single convex form. Direct vertex pushing is better fitting here.