Part request:
50986pb005 Windscreen 10 x 6 x 3 Bubble Canopy Double Tapered with Light Bluish Gray Jedi Starfighter, Handle and Two Red Triangles on Top Pattern
Bricklink:
I couldn't resist trying to do this part (best regards to Rene ).
Whilst it turned out the print isn't as complicated as I initially thought, there are still a lot of issues. Also given the rather complicated nature of the base part, I thought it best to make a forum post before refining things further and put in on the Parts Tracker.
1) Sub-File Structure:
One of the main goals was to keep the original crater plate as is.
Both the main file and the sub-files can only be used by this part anyways, so I assume this will not become an issue?
Should this keep it's current 4 sub-files, or should they be merged into a single monolithic file like the base part?
I also might need to do some local triangle splits to make the ridge less 'blocky' I guess...
2) Pattern Inconsistency:
I used both my own plate and some photos mostly sourced from Ebay as reference. Unfortunately I only have one of these plates, so I couldn't test how they align to each other in reality.
I assumed that ideally these should be able to form a continuous 'river' when put alongside each other. The small colour spots on the edge however seem to be problematic here, as some don't seem to be aligned to the edge on the opposing side.
For the current pattern I 'idealised' the orientation of the spots, so that they do align, assuming this issue is caused by print mis-alignment.
I am not sure if I overdid this, so I would like to get some feedback before I refine the pattern further.
3) 'Mountain' Foot:
On the real part, the darker blue of the mountain print bleeds a bit onto the flat base. Yet again, it looks a lot like this was unintentional. Currently I assumed the dark colour ends right were the sculpted mountain ends. I also assumed that the lighter colour follows the ridge of the mountain as close as possible.
Do you think is correct or should the colour extend more on the floor?
4) Unknown Blue Ink:
This plate's base colour is Light Blue (which is a VERY rare colour on real parts). However, almost the entire top surface of this part is covered in paint, so not much of this is actually visible.
There is a total of 3 ink colours present on the part: Black, Blue and a shade of blue I was unable to identify (it's definitely not Medium Blue). Please keep in mind, that this part was released in 1996 where there were not that many shades of blue available. I am suspecting it could be Maersk Blue, but I don't have parts in that colour to compare. On screen, Medium Azure looks very close, but of cause that wasn't available in 1996.
Does anyone here have both this plate and a Maersk Blue part to compare?
5) Approximating Dithered Colours:
A lot of this part is actually covered in dithered colour blends, which I would usually approach by tiny triangles like in https://library.ldraw.org/parts/37577. However since this part is already quite huge, I am a bit reluctant to increase it's polygon count even further. Everything that is currently coloured as 9 Light Blue is actually a dithered blend of the Light Blue base and the unknown medium blue ink (creating a colour I am not sure how to approximate). The dark blue areas are a color gradient between Black and Blue. I kind of dislike using colours that are definitely not present on the real part, but in this case I see little alternatives.
I also considered direct colour values or Texmaps, but I am a bit afraid of compatibility issues (Stud.io wasn't happy with this approach). Should I keep the current approach?
Hello!
I am not a programmer so I am sorry if I do not use this forum properly.
I was using Studio to make some LEGO pirate themed MOCs, but I noticed it misses some parts, that can be useful.
I read the forum rules, so I will try to post those parts properly.
Please bear with me- I am very much new to this whole thing- my 10 year old son loves to create his own Lego models and it has been his dream to create instructions to share with his friends. I’m trying to assist him, I discovered LDCAD and learned the basics in how to use it, then got him started. We got his first model completed, spent quite a bit of time refining the steps and getting it all figured out, then imported it into LPub3D to create the instructions. The first time we opened it, it was fine, then we started editing things and got the cover page looking nice. When we went further, we discovered something that needed to be fixed, so went back to LDCAD to edit that. We had both programs running, which I think was a mistake because then they kept asking if we wanted to update what the other program had changed, and I think we made the wrong choice at some point. In the process of figuring that out, we lost a bunch of edits, but then realized we needed to just run one program, do the edits and save before going to the other program to continue. Once we finished our edits in LDCAD, we went back to try and work on the instructions in LPub3D and it gives us this error- “step with INSERT COVER_PAGE meta command cannot contain type 1-5 line. Invalid type at line 31 (file:main.ldr, line:30) “. I’m at a loss on how to resolve this- I assume there’s is some piece of code that needs to be edited, but I don’t know how to get to it or what to change it to. That’s all kind of beyond my scope of understanding at this point- I am willing to learn if I can, but haven’t been able to find the right info on how to fix that. Can someone help me understand what/how to fix this? Thanks.
The 2024-10 LDraw Parts Update has been released. This update adds 390 new files to the core library, including 304 new parts and 7 new primitives.
Thanks are due to all the part authors who created or corrected parts for this release. The small, but dedicated, band of reviewers also play an important role in keeping files moving through the Parts Tracker and deserve just as much credit. This update wouldn't have been possible without their dedication and attention to detail.
You can preview the new parts in 2024-10 here, and download the zip-file update or Windows install package here.
Thank you to all the testers and parts authors who continue giving feedback on the PT software. This project would not be what it is without your help.
What is the meaning of a purple conditional line in LDPE? Most conditional lines are yellow/orange, but every once in a while even primitives have single purples here and there.
Hello, as stated here: t04i8000-075.dat
we may need an addon for new torus prim variants...
as of now, there are only full or quarter (inside/outside) torus prims.
But sometimes we may need cut tori. https://en.wikipedia.org/wiki/Toroidal_a...oordinates
toroidal is bigringwise (the rotation path), poloidal is smallringwise (the rotated profile)
my suggestion would be a suffix (like the -075)
and the number is the percentage of the full quarter inside/outside torus and the + or - is the direction
(from the inner/outer border or from the center line)
but you are free to discuss
(do we even need this? which way should it be done? 075 or 750? where does +/- start? and more...)
maybe the *.conn file format is already known but in case its not you can find the description below. I’m also referring partly to the thread “Studio Connectivity Data“ where the question was asked how the *.conn file format is defined.
Connectivity files, e.g., the file definition is actually not too complicated to understand. However, it is more complicated as the collision files just because there are more of them and they are encrypted.
It is true that Part Designer converts the *.conn files -contrary to the *.col files- to a binary format (due to whatever reason). But this does not mean that you cannot access the information, you just have to use a trick. If you generate a part file in Part Designer and store it as *.part it contains all information about the brick. The geometry, the connectivity info and -hidden in the part geometry- the collision data. To see the connectivity info in human-readable format only thing you have to do: Start with a new part but only add connectivity elements (no geometry). In the part editor you will see an empty workspace but in the connectivity editor you can see the connectivity element. If you store this part now as *.part you can open and read it in a text editor (the conversion to binary takes places during export; not internally). From here it is rather a matter of changing the individual values/variables in *.part file and check what are the consequences. Below an image from the STUD connectivity element e.g. the file format:
Figure 1.1: Connectivity file format for the STUD connectivity element (associated *.part file)
I’ve been playing around with these values and compared it with the other connectivity elements. What I’ve found out so far:
First block: 0 (always the same) Second block: PE_CONN (always the same, mostly likely a meta command; Part Editor Connectivity maybe) Third block: ID1 (group ID see figure 1.2 below) Fourth block: ID2 (element ID see figure 1.2 below) Fifth block: 1 0 0 0 1 0 0 0 1 (always the same, Transformation matrix)* Sixth block: XYZ (Position of the element) Seventh block: 2 2 (always the same; geometry data aka visual representation of the element)** Eight block: 3:1,0:4,3:1,0:4,10:4,0:4,3:1,0:4,3:1 (always the same; geometry data aka visual representation of the element)***
* For other elements not always the identity matrix; see figure 1.2
** Lateral size. If you change it from 2 2 to 1 1 it has half the size. But any other value does not work
*** Most complicated one. I guess it describes or are related the geometry of the connectivity element itself (squares in the corner, disc in the center and the connection lines). If you change 10:4 to 20:4 for example the disc changes its form from a disc to a ring. Some of the numbers fit roughly to the size of the connectivity element.
One can argue that during the export Part Editor adds additional data but I’ve also checked this. I’ve generated a *.part file with connectivity elements and exported it to Studio. The associated connectivity file (*.conn) I’ve opened in Part Editor and saved it as *.part again. If the exporter from PE adds additional data to the *.conn file these files should be different but there are the same (I’m assuming PE does not remove data during import).
In figure 1.2 you can see the *.part file with all connectivity elements you can choose from the menu. There are 43 of them. Sorted by ID1. You can see the similarity between these elements. Only the seventh and eights block is different. I guess the above file format also applies to these files (more or less).
Figure 1.2: Connectivity file format for all connectivity elements you can pick from task bar
In figure 1.3 you can see all connectivity elements in the connectivity editor (sorted by group).
Figure 1.3: Connectivity elements in Part Designer
I was building some airplane MOC but there a couple of parts not found in the Studio. Is there anyone could help create those parts? Thanks heap!
5124 - Aircraft Fuselage Aft Section Bottom 6 x 8 x 4 with 4 x 6 Cargo Door Cutout, 2 Holes and 2 Pin Holes
67241pb01 - Aircraft Fuselage Forward Top Curved 8 x 12 x 6 with 6 Window Panes with Molded Trans-Light Blue Glass Pattern
92847 - Cockpit 9 x 6 x 4 1/3, Tapered with Studs on Front
67245 - Aircraft Fuselage Aft Section Curved Top 8 x 12 with 6 Holes
maybe the *.col file format is already known but in case its not you can find the description below. I’m also referring partly to the thread “Studio Connectivity Data“ where the question was asked how the *.col file format is defined.
Collider files e. g. the file definition is actually not too complicated to understand. I’ve not checked all *.col files in the Studio LDraw folder but some of them. Hence, I cannot tell you if the file format applies to all files, but it applies to the ones I’ve checked. Below a snapshot from the collider file for brick 3005.dat (named 3005.col).
Figure 1.1: Collider file for brick 3005.dat (1x1 Brick)
Each line in the *.col files describes one collision box. All lines (boxes) together form kind of collider brick. Whenever two of these collider bricks are touching each other, the associated brick went transparent in Studio which indicates a collision (if the function is activated in Studio).
The file format from one collision box is as follows:
First block: 9 (always the same) Second block: 0 (always the same) Third block: 1 0 0 0 1 0 0 0 1 (1st part of a transformation matrix; always the same)* Fourth block: X Y Z (2nd part of the transformation matrix; position of the collision box) Fifth block: W H L (size of the collision box) Sixth block: null (always the same)**
* Some of the *.col files store this block as 1 instead of 1.000
** This block only exists in the earlier *.col files (at the same time Studio beta was launched; maybe a coincidence).
I’ve written a very simple and basic program that converts a *.col file into a *.ldr file using the box.dat primitive (one primitive for each collision box). The above file is then called 3005COL.ldr. In figure 1.2 below you can see the collider brick in red. In figure 1.3 I’ve superimposed the collider brick and the real brick itself (brick 3005 is drawn transparent for clarification).
Figure 1.2: Collider brick for brick 3005
Figure 1.3: Collider brick and brick 3005 superimposed
One can see that the collider brick is a little bit smaller as the brick itself. This can be verified with Studio also. The collision warning does not occur directly after the bricks have contact but a little later. See figure series below.
Figure 1.4: Two 1x1 bricks separated. Collision warning in Studio activated. No collision detected.
Figure 1.5: Two 1x1 bricks just touching each other. Collision warning in Studio activated. No collision detected.
Figure 1.6: Two 1x1 bricks collided (they intersect a little bit). Collision warning in Studio activated. But no collision detected.
Figure 1.7: Two 1x1 bricks collided (they intersect a bit more). Collision warning in Studio activated. Now the bricks turn transparent to indicate a collision.
To show the geometry of more complex collider bricks, I’ve also converted the *.col files for part 10a (Baseplate 24 x 32), 64713 (Cone Spiral Jagged - Step Drill) and 59278 (Boat hull, Hull Unitary 74 x 18 x 7 with Light Bluish Gray Top). The first one is a part with multitude of studs, the second one a complex shaped part and the latter one of the largest file in the *.col folder. See images below.
Figure 1.8: Collider brick for part 10a.dat (Baseplate 24 x 32)
Figure 1.9: Collider brick for part 64713.dat (Cone Spiral Jagged - Step Drill)
Figure 1.10: Collider brick for part 59278.dat (Boat hull, Hull Unitary 74 x 18 x 7 with Light Bluish Gray Top)
And some close ups from 10a.dat and 59278.dat.
Figure 1.11: Close-up from the collider brick for part 10a.dat
Figure 1.12: Close-up from the collider brick for part 59278.dat
Hope the above explanation helps to get an impression how studio calculates collisions.
).
