Romania
Joined: Apr 24, 2014
Post Count: 819
Status:
Offline
Re: Modeller 3D plugin
@Xlance I'm not going to argue with you.
The Outset and Inset buttons don’t do what they’re supposed to ... What are they supposed to do? (Scaling is done by dedicated x, y, z inputs)
This option wasn’t in your previous version. Even so, Outset/Inset were supposed to perform uniform scaling relative to the center of the selection, not an extrusion. With the dedicated input fields, it’s a solution for the standard xyz directions but not for other positions.
Please add your new code to this v1.4.5 which has some extra functions and adjustments
I've already added it, but it seems that doesn't matter to you. That's what I sent you: And this is what I got back from you: I'll leave it up to the users to decide.
Please keep code structure as is 11 files :-)
I can't promise you that. There were already 15 files. There will be no more and no fewer than necessary. I can combine everything into a single file, just as you started, containing 10,000–15,000 lines of code (excluding comments). That's possible because there are currently only 7,476 lines.
github.com/AlDanial/cloc v 2.04 T=0.10 s (383.8 files/s, 112293.2 lines/s) ------------------------------------------------------------------------------- Language |files_ |blank |comment |code ------------------------------------------------------------------------------- Java ______ |__ 14 |_ 1070 |_____ 758 |__ 7476 Properties |__ 19 |__ 343 |_______ 74 |__ 1180 INI _______ |___ 3 |_____ 0 |________ 0 |___ 407 Text ______ |___ 1 |_____ 4 |________ 0 |____ 68 XML ______ |___ 2 |____ 0 |________ 0 |____ 30 ------------------------------------------------------------------------------- SUM:_____ |__ 39 |_ 1417 |______ 832 |__ 9161 ------------------------------------------------------------------------------- I think I’ll stop working on this plugin and focus on others—or, better yet, I’ll just enjoy my new life as a retiree. According to statistics in Romania, people in my category live, on average, until age 68. So I have three years left. Anything beyond that is a bonus.
Translated with DeepL.com (free version)
---------------------------------------- A computer program does what you tell it to do, not what you want it to do. Murphy's Law When all else fails, read the instructions. Murphy's Law If you don't like "AS IS", DIY. Dorin's law
----------------------------------------
[Edit 1 times,
last edit by dorin at Apr 9, 2026, 11:29:18 PM]
Joined: Mar 23, 2020
Post Count: 116
Status:
Offline
Re: Modeller 3D plugin
Nice layout :-) I'll try to add the extra functions to your design Cheers
---------------------------------------- Windows 64bit | Intel i7 | 8GB Ram | SH3D 7.5 + Plugins
Romania
Joined: Apr 24, 2014
Post Count: 819
Status:
Offline
Re: Modeller 3D plugin
Don't rush—give this version a try. I would like you to fix the issue with face grouping when multiple adjacent faces are selected (as was the case in my version with triangles). This is especially necessary for the extrude operation. The newly created faces should enclose the entire selection, not each face individually. I plan to add a panel for scaling and one for extruding. After a few changes, the Undo/Redo feature is behaving strangely. I'll add your new text import option in the right place. There remains the issue of unwanted holes being created when modifying an edge of a face that has just been split. With triangles, this happens very rarely.
---------------------------------------- A computer program does what you tell it to do, not what you want it to do. Murphy's Law When all else fails, read the instructions. Murphy's Law If you don't like "AS IS", DIY. Dorin's law
Romania
Joined: Apr 24, 2014
Post Count: 819
Status:
Offline
Re: Modeller 3D plugin
My final dialog with one of the AI after few days of trying and fail.
Q: With TRIANGLE_ARRAY shapes work as expected but with QUAD's don't. Could QUAD_ARRAY to not be proper solution for modeling shapes?
A: Yes, this is a fundamental representation problem. QUAD_ARRAY is the wrong primitive for general 3D modeling, and here's why: QUAD_ARRAY limitations • Quads are not guaranteed to be planar. After extrusion, scaling, or any non-uniform deformation, the 4 vertices of a face will generally not lie in the same plane. The renderer then silently splits each quad into 2 triangles — but it picks the split diagonal arbitrarily, producing inconsistent shading, incorrect normals, and visual artifacts. • Shared vertex topology is not expressible. QUAD_ARRAY (like TRIANGLE_ARRAY) is an unindexed flat list — each face owns its own 4 vertices, so adjacent faces don't actually share vertices. This means: ◦ Welding/merging operations require explicit de-duplication ◦ Normal smoothing across edges is unreliable ◦ Operations like your extrude must manually track edge adjacency (your edgeUsage map is a workaround for this missing structure) • Winding order ambiguity is worse with quads. With triangles, the cross product always gives an unambiguous normal. A non-planar quad has no single well-defined normal — different renderers resolve this differently.
What professional modelers use The industry-standard internal representation is a half-edge mesh (also called a winged-edge or doubly-connected edge list): Vertex → outgoing HalfEdge HalfEdge → next, prev, twin, face, vertex Face → one HalfEdge This gives you O(1) access to: • All faces around a vertex • Both faces sharing an edge • All edges around a face • Boundary detection (twin == null) Operations like extrude, bevel, loop cut, and subdivision become clean algorithms rather than index-hunting workarounds. Blender, Maya, and Wings3D all use half-edge internally, rendering to triangles only at display time.
Practical recommendation for your codebase A full half-edge refactor is large, but a meaningful intermediate step is switching to an indexed triangle mesh with explicit adjacency:
class Mesh { List<Point3f> vertices; // shared, indexed List<int[]> triangles; // 3 vertex indices per face List<String> faceNames; // Derived on demand, not stored redundantly: Map<String, int[]> edgeToFaces; // "vA-vB" → [faceLeft, faceRight] }
• Triangles are always planar — no ambiguity • Shared vertices are explicit — smoothing and welding are trivial • Boundary edges are simply edges where edgeToFaces has only one entry — your edgeUsage map, but built into the structure • Extrude, bevel, and subdivision algorithms are well-documented for triangle meshes The rendering side doesn't change at all — you're already outputting triangles to the GPU anyway. QUAD_ARRAY was just an illusion of quads on top of triangle rendering.
Q: Good. Where to put and use this class? Or I need to start all from scratch?
A: You don't need to start from scratch. The cleanest approach is to use Mesh as an internal working representation inside SolidShape, converting to and from it only at the boundaries — load and display.
Current architecture (guessed from your code): SolidShape List<Point3f> vertices ← flat, unindexed List<int[]> faces ← QUAD_ARRAY indices List<String> faceNames
// Converters (called at load/save/render boundaries only) void fromQuadArray(...) ← import legacy data int[] toTriangleArray() ← export to renderer
// All editing operations now delegate to mesh addVertex(), addFace(), etc. The rest of your codebase — ShapeNode, the editor, undo/redo via takeFullSnapshot() — touches SolidShape only, so they don't need to change.
Where each piece lives: Mesh.java ← new file, pure geometry, no rendering List<Point3f> vertices List<int[]> triangles ← always tris, always planar List<String> faceNames Map<String,int[]> edgeToFaces ← built on demand
SolidShape.java ← owns a Mesh, exposes editing API Mesh mesh fromQuadArray() ← called once on load/import toTriangleArray() ← called by ShapeNode at render time takeFullSnapshot() ← serializes mesh state for undo restoreSnapshot()
ShapeNode.java ← no changes needed update() ← calls ss.toTriangleArray() as before
Editor / directionalExtrudeSelected() ← operates on SolidShape API ← no longer touches faces/vertices directly
Migration path — incremental, not a rewrite: Step 1 — Add Mesh.java, keep everything else unchanged. No breakage. Step 2 — Add SolidShape.fromQuadArray() and SolidShape.toTriangleArray(). Wire toTriangleArray() into the existing render path. Validate visually — shapes should look identical. Step 3 — Rewrite one operation (e.g. directionalExtrudeSelected) to work on mesh internally. Everything else still uses the old path. Test that one operation. Step 4 — Migrate remaining operations one by one. Each is independently testable. Step 5 — Once all operations use mesh, remove the old vertices/faces lists from SolidShape.
The snapshot/undo system is the only tricky part. Your current takeFullSnapshot() presumably serializes the flat arrays. You'll need to update it to serialize Mesh instead — but the interface (float[] before = ss.takeFullSnapshot()) doesn't need to change, just the implementation.
So in short: create Mesh.java as a new standalone class, embed it in SolidShape, and migrate operations one at a time. The editor, renderer, and undo system stay structurally the same. The total surface area that needs changing is just SolidShape internals.
(I've implemented the recommendations.)
Q: Thanks! It is worse now. I'll return to triangles. Probably at the end (when finally exported) could be converted to Quad.
A: That's the right call. Keep triangles internally, convert to quads only at export if needed. Let's go back to the clean triangle-based version without the Mesh layer — simpler, working, and honest about what the geometry actually is. To make sure I give you exactly the right code: which part is broken — is it directionalExtrudeSelected specifically, or did the Mesh.fromSolidShape / toSolidShape conversion also corrupt other operations like selection highlighting or undo?
Q: Doesn't mater. I have to make few steps back to a specific point and continue on another direction.
A: Understood — sometimes the cleanest move is to roll back to a known good state and branch from there. Good luck with the new direction, and feel free to come back when you need another pair of eyes on the code!
Here is my last version on this direction.
---------------------------------------- A computer program does what you tell it to do, not what you want it to do. Murphy's Law When all else fails, read the instructions. Murphy's Law If you don't like "AS IS", DIY. Dorin's law
+ Introduced UI Flatlaf dark mode. + Re-introduced old Extrude code in addition to dorin's new functions. + Adjusted / Aligned UI elements for more orderly interface. + Screen size is reduced a bit to a fixed 1200x730 px. + Minor tweaks.
Netherlands
Joined: Apr 8, 2022
Post Count: 1772
Status:
Offline
Re: Modeller 3D plugin
First impression: looking great! I use the BlackMate theme on my Linux install which makes all Linux programs that follow the design rules use that theme. The Flatlaf dark mode looks very good, much easier on your eyes.
First remark: The click+drag preview movement is still "the wrong way round": When I move the mouse down the preview goes up. When I move the mouse right the preview turns left. Compare it to the 3Dview in Sweet Home 3D. It's very disconcerting to have opposite movement when you start a plugin after using the Sweet Home 3D 3Dview.
I will play some more and let you know what I find.
Excellent job so far!
---------------------------------------- Dodecagon.nl 1300+ 3D models, manuals, and projects
Netherlands
Joined: Apr 8, 2022
Post Count: 1772
Status:
Offline
Re: Modeller 3D plugin
Have you noticed that the plugin interferes with the Sweet Home 3D UI after usage? The scrollbar handle (between the 2D and 3D views) and the 2Dview grid have changed after closing the plugin window.
The navigation click+drag with the mouse is unchanged and still turns the wrong way, both left/right (rotate) and up/down (tilt).
I didn't notice the free draw selection area before, a very, very useful feature. But... area selection still includes elements behind the select area. In other words, if I select the front of a sphere, the hidden faces at the back are also selected. That makes the area select virtually useless. Area select should only select the visible elements inside the drawn area.
Does Java have collapsible panel controls?
---------------------------------------- Dodecagon.nl 1300+ 3D models, manuals, and projects
Joined: Mar 23, 2020
Post Count: 116
Status:
Offline
Re: Modeller 3D plugin
Have you noticed that the plugin interferes with the Sweet Home 3D UI after usage? The scrollbar handle (between the 2D and 3D views) and the 2Dview grid have changed after closing the plugin window.
Fixed. Flatlaf does not leak to UI after closing.
The navigation click+drag with the mouse is unchanged and still turns the wrong way, both left/right (rotate) and up/down (tilt).
Fixed.
I didn't notice the free draw selection area before, a very, very useful feature. But... area selection still includes elements behind the select area. In other words, if I select the front of a sphere, the hidden faces at the back are also selected. That makes the area select virtually useless. Area select should only select the visible elements inside the drawn area.
Fixed. Note that edges/faces are selected if inside or 'crossing' selection area.
