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

René

Hello everyone,

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 

Hope the helps.

Best,
Gabe

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

Hello everyone,

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.

Best,
Gabe

i need front side maybe back top and bottom pics of sandy head id 61285
maybe fish head id 61286

Thread for Wednesday license sets

LDCAD already has the ctrl+right-click function for multiple selections. Is it possible to add a selection function similar to Blender?For example selection Circle and selection Lasso?I think this will be more convenient to operate

Hello everyone,

I had an idea and was wondering if this might be something worth looking into.
There was an older post regarding the issue, but it seems this was without solution:
https://forums.ldraw.org/thread-27623.html

Is it allowed to use a mixture of "normal" patterns and Texmaps to simulate the effect of certain holofoil stickers (like in 6991 or 6949)? Seems a bit unusual to me, but in theory it works.

Here is a quick test shot I made:
   

Probably need to get a better image of the foil and get the scaling more accurate to the real stickers. Perhaps this single image can even be used on all those "dotted" stickers.

However, there seem to be issues when exporting to other formats or Stud.io

Hello, I need help numbering (and composing) a part...
I dont have the physical part but got good pics from Ddriver, so the part itself is nearly done.
   
Part(s) in question: x871a/b
http://www.peeron.com/inv/parts/x871a
http://www.peeron.com/inv/parts/x871b
https://www.bricklink.com/v2/catalog/cat...a#T=C&C=12
https://www.bricklink.com/v2/catalog/cat...b#T=C&C=12
https://rebrickable.com/parts/upn0313a/c...functions/
https://rebrickable.com/parts/upn0313b/c...functions/
from the outside, its the same brick, but the B version has some electronics inside to reverse it.

Now the big question: how should that get split (and numbered)?

Its consists of base (black) electronics (dark tan) and cover (clear)
BL and Peeron have the main (paintable) color clear and the base is hardcoded black.
I would use u9618-20, each in a and b like the microphones u9616.
a is the older Forward/Stop and b the newer Forward/Stop/Backwards
Should i use u9617 for a split microphone bottom?

René

Hello community

Could you tell me if there is any way to improve the quality of the exported files as .stl (increase the amount of polygon)?

thanks