| Welcome, Guest |
You have to register before you can post on our site.
|
| Online Users |
There are currently 263 online users.
» 2 Member(s) | 255 Guest(s)
Applebot, Baidu, Bing, Facebook, Google, Yandex, Gerald Lasser, Jeff Jones
|
| Latest Threads |
Change of 70681
Forum: Parts Authoring
Last Post: Magnus Forsberg
3 hours ago
» Replies: 1
» Views: 91
|
missing parts for star wa...
Forum: Parts Authoring
Last Post: Jeff Jones
Yesterday, 16:11
» Replies: 5
» Views: 3,076
|
7194-1 Yoda
Forum: Official Models
Last Post: John Troxler
Yesterday, 15:44
» Replies: 0
» Views: 120
|
Teenage Mutant Ninja Turt...
Forum: Official Models
Last Post: Jeff Jones
Yesterday, 11:54
» Replies: 1
» Views: 163
|
Request for new primitive...
Forum: Parts Authoring
Last Post: Magnus Forsberg
Yesterday, 11:04
» Replies: 4
» Views: 606
|
Mr. Incredible's Torso
Forum: Part Requests
Last Post: Stefano
2026-03-24, 11:53
» Replies: 4
» Views: 5,913
|
Insert background picture...
Forum: LDraw Editors and Viewers
Last Post: Roland Melkert
2026-03-23, 21:38
» Replies: 3
» Views: 839
|
Feature request - Add cur...
Forum: LDraw Editors and Viewers
Last Post: Roland Melkert
2026-03-23, 21:36
» Replies: 7
» Views: 1,599
|
Looking for some Ninjago ...
Forum: Part Requests
Last Post: Jason Osicki
2026-03-23, 1:10
» Replies: 7
» Views: 1,218
|
James Jessiman Memorial A...
Forum: LDraw.org Announcements
Last Post: Gerald Lasser
2026-03-22, 21:27
» Replies: 7
» Views: 691
|
|
|
| Question about aring usage in library |
|
Posted by: Travis Cobbs - 2026-03-18, 5:39 - Forum: Parts Authoring
- Replies (7)
|
 |
I am (finally) working on supporting the aring primitive in LDView's primitive substitution, and I have run into what I feel is a problem. The problem is that I believe that the aring can be used in two different ways:
- To fill in the gap between a standard-resolution curved primitive and a 48-resolution curved primitive
- To fill in the gap between 16-sided geometric curve and a 48-resolution curved primitive
I know that it is being used in situations that match option 1 above. I don't know if it is being used for option 2 or not. One (relatively minor) problem is that option 1 is incompatible with how LDView does primitive substitution when the curve quality is set to certain settings. I should be able to fix this. But there is no way for me to generate the primitive in a way that is compatible with both option 1 and option 2.
For option 1, the resolution of the inner part needs to track my primitive substitution curve quality, and the outer part needs to track the 48-resolution version of the same thing. When the quality is set to the default value, this would be 16 and 48. For the next notch on LDView's quality slider, the 16 becomes 24. Right now, the 48-resolution version remains 48 at that setting. (That would probably change. The next notch uses 32, and since 32 doesn't evenly divide into 48, that would have to change. Same for the next notch, which is 40. An easy solution is to use 64 and 80 for the 48-resolution version of those two notches.)
But if this primitive is used next to hard-coded 16-sided geometry, then the inner resolution would need to remain 16, no matter what the curve quality is set to. The current description for the aring primitive does specify that it interfaces between high-resolution primitives and normal-resolution primitives. So does this mean that interfacing with 16-segment geometry is not allowed? If so, I can make it work (although it will cause my primitive substitution to render more geometry for 48 curves when the curve quality is set to use 32 or 40 segment curves).
If it is used next to 16-segment geometry, then I feel that that needs to be forbidden, and a new primitive needs to be introduced to fill that (different) role.
Side note: for POV export, the first version of this primitive is no geometry at all. The second version is a chord.
|
|
|
| Victims of no autosave |
|
Posted by: Jeff Jones - 2026-03-16, 20:12 - Forum: Parts Authoring
- Replies (2)
|
 |
as you know one of the biggest flaws of ldparteditor is its lack of an autosave, i lost the age of ultron hulk i was working on thanks to it
this would be where you share the parts you lost thanks to it
for me
that chima 2014 armour, smart play x play cockpit, and the aforementioned hulk
pls add it nils
|
|
|
|
| Simple procedural geometry proposal |
|
Posted by: Max Murtazin - 2026-03-16, 9:50 - Forum: Official File Specifications/Standards
- Replies (3)
|
 |
So, this is a thing I've thought about for a while. In a lot of cases, the way LDraw handles the geometry is, to put it simply, inefficient for the task it is trying to achieve. Parts that rely on circular geometry, such as covered by edge and disc series of primitives, a lot of the time, have to rely on some sort of, for lack of a better word, hacks to achieve the desired geometry. Probably, most basic case of that would be a disc with a circular cutout (while achievable by both a primitive series of a honestly horrendous size - n-fringr.dat, or, in some cases, by a simple, yet polygonally very inefficient combinations of chrd and ndis primitives), or, a case where a simple trick is incapable of achieving the goal, requiring either a combination, or creation of new primitives (a primitive series of similarly horrendous size that is n-fconr.dat).
Solution to that I want to propose is deceivingly simple - a new meta command, let's for now just call it "draw", as the name is not that important. Use of it would be fairly simple:
Code: 0 !DRAW <method> <generated geometry color> <additional parameters>
0 !: <input geometry information>
First method I'll propose is called "FILL". FILL would take in 2 lines of planar edge geometry, and fill them with a consequent line of quads, adding the required optional lines between them in the process, if the input edges don't lie on the same plane. In that case, if we need to draw a cone with top circle specified by a line with transform matrix <parameters a> and top circle with transform matrix <parameters b>, it would be doable with the following META:
Code: 0 !DRAW FILL 16
0 !: 1 24 <parameters a> 4-4edge.dat
0 !: 1 24 <parameters b> 4-4edge.dat
An obvious input limitation arises of input geometries having to match in amount of lines, and the input lines to be connected having to be in the correct order, but at least as far I can see, the input geometry would likely never have to be anything other than same circular shape before transformation, maybe in some variations of edge/no edge. If that is the case, meta could be simplified to only pass the matrices as the parameters, and geometry could be specified as a unified parameter
Second method I'd like to propose is called "REVOLVE". As the name implies, method's intent is to create a solid of revolution from the input geometries, placing optional lines accordingly. While this one does have a lot of potential, best case for this one my mind could conjure is making a truncated cylinder of an arc that isn't a multiple of 16 without having to compromise by filling the rest of it with a plane that would likely not have the best appearance with primitive substitution enabled. Use case is as following:
Code: 0 !DRAW REVOLVE <generated geometry color> <angle> <revolution axis>
0 !: <input geometry information>
Angle is specified in radians (arc length)
Revolution axis is specified by a set of 2 points - x1 y1 z1 x2 y2 z2
Input geometry information is specified by a line type 1
Most likely, some other methods of generating geometry could also be used, but, as far as I can see, only these two are worth considering, as they cover the most important points of possible improvement, while not being computationally expensive or difficult to implement
|
|
|
|
|
