Studio parts editor, decals, connectivity...

[Philippe Hurbain]

https://www.bricklink.com/v3/build/partdesigner.page
...looks interesting!

[Gerald Lasser]

https://www.bricklink.com/v3/build/partdesigner.page
...looks interesting!

Hm, indeed! Interestining

[Victor Di Rienzo]

https://www.bricklink.com/v3/build/partdesigner.page
...looks interesting!

excellent!!!!! good news. this iwll speed up very much the process.

i hope this guys enable exporting the models to ldraw.

[Philippe Hurbain]

Part designer is out. Rather impressive...

[Victor Di Rienzo]

the app its super fast to make patterns

the main problem its how it does export the pattern that looks that its not ldraw compliance.



Select the brick you want to apply the pattern



select the pattern




and export it thats all in 2 minutes you have it. btw you need a good quality pattern.


the exprot to ldraw looks like..

[Philippe Hurbain]

The method used by Studio is very similar to LDraw texmap (and as such is not soooo much faster to create - but for sure more convenient ). I believe it could be possible to write a conversion tool. The long sting after "PE_TEX_INFO" is the png image, encoded in base64 (there is a working decoder here: http://www.webutils.pl/Base64)

[Orion Pobursky]

The method used by Studio is very similar to LDraw texmap (and as such is not soooo much faster to create - but for sure more convenient ). I believe it could be possible to write a conversion tool. The long sting after "PE_TEX_INFO" is the png image, encoded in base64 (there is a working decoder here: http://www.webutils.pl/Base64)

I’m curious why they chose to “roll their own” solution instead of using the already existing texmap support for LDraw. I like Studio but I’m having a hard time recommending it because they’re not giving back to the LDraw project.

[Philippe Hurbain]

I’m curious why they chose to “roll their own” solution instead of using the already existing texmap support for LDraw.

I'd like to know too...

I like Studio but I’m having a hard time recommending it because they’re not giving back to the LDraw project.

Not completely true now since Studio part admin is a new but active LDraw part author!

[Orion Pobursky]

I'd like to know too...
Not completely true now since Studio part admin is a new but active LDraw part author!

That’s great news. I’ve been trying really hard not to bash BrickLink since I like their product a lot. Past encounters left a bad taste in my mouth but a lot has changed with them and I don’t want to hold a grudge.

[Vincent Messenet]

I'd like to know too...
Not completely true now since Studio part admin is a new but active LDraw part author!

Hi, I must precise that I am independant from Studio and Bricklink team.

I discovered Studio after LDD stopped to be officially maintained and mainly used it because it was very user friendly and I didn't know much about how Ldraw worked at that time.
Then as a lot of parts were missing at that time I started to help the team to integrate missing parts within Studio and especially providing them mapping between Ldraw parts and Bricklink identifiers. Due to this they proposed me to handle their sub-forum "Studio Parts" where people reports issues and ask for new parts to be integrated and I am mainly doing the link between users and Studio team about parts integration topics. By the way thank you Philippe for your help replying to some posts

Then the more time I spent on this the more I wanted to start designing parts by myself and that's why I started a couple of weeks ago to learn and submit parts to Ldraw Library.

[Orion Pobursky]

Hi, I must precise that I am independant from Studio and Bricklink team.

I discovered Studio after LDD stopped to be officially maintained and mainly used it because it was very user friendly and I didn't know much about how Ldraw worked at that time.
Then as a lot of parts were missing at that time I started to help the team to integrate missing parts within Studio and especially providing them mapping between Ldraw parts and Bricklink identifiers. Due to this they proposed me to handle their sub-forum "Studio Parts" where people reports issues and ask for new parts to be integrated and I am mainly doing the link between users and Studio team about parts integration topics. By the way thank you Philippe for your help replying to some posts

Then the more time I spent on this the more I wanted to start designing parts by myself and that's why I started a couple of weeks ago to learn and submit parts to Ldraw Library.

Regardless of your “officialness”, glad to have you here and as a part author.

[Victor Di Rienzo]

I’m curious why they chose to “roll their own” solution instead of using the already existing texmap support for LDraw. I like Studio but I’m having a hard time recommending it because they’re not giving back to the LDraw project.

im having mix fellings with studio, looks like they took advantage of ldraw and they are doing their own solution, but not making fully compatible backwards. and not giving back.

i only recomend studio for render only.

[Travis Cobbs]

I’m curious why they chose to “roll their own” solution instead of using the already existing texmap support for LDraw. I like Studio but I’m having a hard time recommending it because they’re not giving back to the LDraw project.

We actually discussed base64-embedded texmaps. I even implemented (currently unreleased) support for the suggestion we came up with in LDView. But our proposed syntax was never made official anywhere. And it relies on MPD syntax.

[Victor Di Rienzo]

The main issue here independent of how will be implemnted the texrure support.

Ldraw library will accept them in part tracker?

[Travis Cobbs]

The main issue here independent of how will be implemnted the texrure support.

Ldraw library will accept them in part tracker?

No, and frankly, I don't personally feel that they should ever be accepted in the parts tracker as generated by the tool. Having said that, I can sympathize with the tool's author's presumable desire to have all the data in one self-contained file. It should be trivial to write a small tool to read these generated files, extract the textures, and update the dat code to reference the textures (stripping out the embedded texture).

[Philippe Hurbain]

By the way thank you Philippe for your help replying to some posts

You're welcome
Thanks for clarifying your status... Anyway I think that some cooperation between both teams can only be beneficial to everybody! I understand that sometimes we have to make compromises, but the biggest compatibility we have, the best it is!!!

[Philippe Hurbain]

The main issue here independent of how will be implemnted the texrure support.

I don't know exactly. Looks like some form of u-v mapping (hence the added parameters to type 3 triangles in textured Studio parts). But in most cases (in particular minifig heads and torsos) it shouldn't be very difficult to convert from one format to the other. Remains the issue of ownership of images in the case of Studio to LDraw conversion.

[Philippe Hurbain]

I don't know exactly. Looks like some form of u-v mapping (hence the added parameters to type 3 triangles in textured Studio parts). But in most cases (in particular minifig heads and torsos) it shouldn't be very difficult to convert from one format to the other. Remains the issue of ownership of images in the case of Studio to  LDraw conversion.

Definitely u-v mapping.This kind of explain the choice of a different method than LDraw texmap, since this method is more powerful (but imho overkill!)
I inserted a regular grid pattern, replacing a standard face decal, and here is the result in Studio. If it was simple cylindrical mapping, the top and bottom lines wouldn't appear there. Note the strange wiggles of lines that should be straight...
   

[Victor Di Rienzo]

For me the fastest way to perform the patters may be designing them in 2d in adobe ilustrator or corel draw or inkspace. Then export the design into svg format ( "SVG is a widely-deployed royalty-free graphics format developed and maintained by the W3C) it uses xml. http://www.w3.org/Graphics/SVG/

Having the design ready in svg format there you have all the information to "trace it" and convert it to ldraw triangles. With a small tool.  after that you can edit and tweak with ldpattern creator or any other editor.

Little explanation about svg https://flaviocopes.com/svg/

[Philippe Hurbain]

A few solutions...

- svg2dat beta utility (written by Travis Cobbs) that does that, but it only handles a subset of svg, and triangulation is not outstanding (can't find again the link).

- Lasse Deleuran's online svg to Ldraw converter: https://c-mt.dk/software/svg2ldraw/ (see also https://www.eurobricks.com/forum/index.p...studio-20/). Interesting too, but again triangulation is not so great, and svg support is not complete either.

- Rolf Osterthun's Img4Dat tool (https://forums.ldraw.org/thread-23242.ht...ht=img4dat). At first it seems a bit awkward as you need to convert your svg to a bmp bitmap (and it's not bug-free), but it's by far the best tool I used to convert images to LDraw patterns. With a good source image, it can even work directly from a part photo, as I did for this torso http://www.ldraw.org/cgi-bin/ptdetail.cg...973p5f.dat

[Victor Di Rienzo]

A few solutions...

- svg2dat beta utility (written by Travis Cobbs) that does that, but it only handles a subset of svg, and triangulation is not outstanding (can't find again the link).

- Lasse Deleuran's online svg to Ldraw converter: https://c-mt.dk/software/svg2ldraw/ (see also https://www.eurobricks.com/forum/index.p...studio-20/). Interesting too, but again triangulation is not so great, and svg support is not complete either.

- Rolf Osterthun's Img4Dat tool (https://forums.ldraw.org/thread-23242.ht...ht=img4dat). At first it seems a bit awkward as you need to convert your svg to a bmp bitmap (and it's not bug-free), but it's by far the best tool I used to convert images to LDraw patterns. With a good source image, it can even work directly from a part photo, as I did for this torso http://www.ldraw.org/cgi-bin/ptdetail.cg...973p5f.dat

Thank you very much philo.

[Damien Roux]

As I'm authoring many patterns the best way I found is to create a svg file of the pattern (Illustrator is my tool of choice as you can work in 1:1 scale with ldraw and benefit of very powerful functionalities) then exporting it to dat using svg2dat. Then retriangulation is needed anyway.

[Victor Di Rienzo]

As I'm authoring many patterns the best way I found is to create a svg file of the pattern (Illustrator is my tool of choice as you can work in 1:1 scale with ldraw and benefit of very powerful functionalities) then exporting it to dat using svg2dat. Then retriangulation is needed anyway.

Can younsharr the executables for svg2dat

[Lasse Deleuran]

- Lasse Deleuran's online svg to Ldraw converter: https://c-mt.dk/software/svg2ldraw/ (see also https://www.eurobricks.com/forum/index.p...studio-20/). Interesting too, but again triangulation is not so great, and svg support is not complete either.

If anyone sees issues with a processed SVG file in svg2ldraw, then please send it to me and I will try to fix it.

I am actively developing all my web-based tools right now as I need them for some building instructions.

[Victor Di Rienzo]

If anyone sees issues with a processed SVG file in svg2ldraw, then please send it to me and I will try to fix it.

I am actively developing all my web-based tools right now as I need them for some building instructions.

check this tool to generate mesh https://www.cs.cmu.edu/~quake/triangle.html

[Travis Cobbs]

Can younsharr the executables for svg2dat

See here.

[Lasse Deleuran]

check this tool to generate mesh https://www.cs.cmu.edu/~quake/triangle.html

Thanks. Another person also referred me to this implementation of Delauney-triangulation. Is it because you would prefer the triangulation to adhere to the Delauney constraint? Please note that this algorithm does not take quads and T-junctions into account.

My current algorithm creates quads and runs a step to prevent T-junctions. These can be added as steps on top of a Delauney triangulation (just like they currently are steps on top of a greedy heuristic), but they will invalidate the Delauney constraint, resulting in a heuristic. The question then becomes. Does creating a heuristic on top of a Delauney triangulation yield a preferred result?

[Lasse Deleuran]

Studio Part Designer appears to be using PE_TEX_INFO in a new way, which I have not encountered before. As an example, the following appears to be a valid usage:

Code:

0 PE_TEX_PATH 0 0
0 PE_TEX_INFO 0.0000 0.5417 -0.9150 1.6100 0.0000 0.0000 0.0000 0.0000 0.6708 0.0000 0.2200 0.0000 -20.0000 26.0000 20.0000 -22.0000 <PNG CONTENT>

This usage appears to be a way of linearly projecting onto only a subset of the primitives in a complete part.


The usage I have been made aware of is using 3245b.dat. Here Studio uses the lines above to project an image onto the part. The correct way of doing this would have been to use the sub-model with a missing face, and then project only onto a rectangle with the texture.


Does anyone know what the parameters for PE_TEX_INFO and PE_TEX_PATH are used for? It seems quite inefficient that we have to reverse-engineer this every time they come up with a new way of not using the standard.

[Orion Pobursky]

I wouldn't oppose you directly contacting the Studio team to ask why they aren't using the official standard. You can even say you're representing LDraw in this matter. I think you might pull a little more weight since your software is being used by Rebrickable.

[Lasse Deleuran]

I wouldn't oppose you directly contacting the Studio team to ask why they aren't using the official standard. You can even say you're representing LDraw in this matter. I think you might pull a little more weight since your software is being used by Rebrickable.

Thanks. I will do this. I should have opportunities to contact them directly from August where I will be in Billund. 

Meanwhile. It seems like reverse engineering and splitting into sub models programmatically is the way forward with this latest change. 

This will unfortunately take a medium effort, and I want to make greater strides with the rounding errors in official primitives first, since that is a more pressing issue. So if anyone finds a solution here in the mean time, then feel free to raise a PR - it will be greatly appreciated.

[Philippe Hurbain]

I want to make greater strides with the rounding errors in official primitives first, since that is a more pressing issue.

I am not sure to understand why you make this such an urgent case. There is soooooo many possible sources of vertex mismatch in LDraw parts, I don't understand why correcting a bunch of prims is so important?

[Sylvain Sauvage]

Thanks. I will do this. I should have opportunities to contact them directly from August where I will be in Billund. 

Studio is from BrickLink and BrickLink is in Irvine, California, USA.

Now, the related question of the incompatibility of texmaps between Studio and LDraw has been raised elsewhere and the devs will look into it.  I don’t know if they will finally adopt LDraw standard everywhere or only use it when you export to LDraw.

[Lasse Deleuran]

I am not sure to understand why you make this such an urgent case. There is soooooo many possible sources of vertex mismatch in LDraw parts, I don't understand why correcting a bunch of prims is so important?

When I asked in the thread, I was told that it was best to also check all part files which use the primitives and correct these. This is an extremely large amount of manual, repetitive and, frankly, utterly boring, work. But if I don't do it, then who will?

There are so many interesting topics to pick up:
- Those errors that you and the team have reported.
- Proper rendering of transparent elements.
- Faster primitive generator.
- Instancing for faster rendering
- Animations
- Generators for LDCad in order to render files quicker (and using less memory)
- Lights
- Scenes
- Automatic instruction steps

But I know that when I focus on these, I neglect the boring stuff that will then not be done.

[Orion Pobursky]

When I asked in the thread, I was told that it was best to also check all part files which use the primitives and correct these. This is an extremely large amount of manual, repetitive and, frankly, utterly boring, work. But if I don't do it, then who will?

Your efforts are appreciated. This is like the patterned part cross reference for the PBG generator. It was a good way to kill dead time but man was it boring.

[Philippe Hurbain]

Sorry if my words sounded harsh, that was really not my intent

[Cam's Bricks]

*snip*
This will unfortunately take a medium effort, and I want to make greater strides with the rounding errors in official primitives first, since that is a more pressing issue. 
*snip*

Can you explain a little more about how one can find these errors? If it is "simple" math is it not able to be done pragmatically with a script of some kind? 

I am way new to the LDraw community and the part creation but I would like to give back and contribute. I have made a decent amount of side income from making and selling instructions using LDraw tools. If my giving back can be doing the boring stuff so you can get on with your list of awesome stuff then so be it.

[Lasse Deleuran]

Can you explain a little more about how one can find these errors? If it is "simple" math is it not able to be done pragmatically with a script of some kind? 

I am way new to the LDraw community and the part creation but I would like to give back and contribute. I have made a decent amount of side income from making and selling instructions using LDraw tools. If my giving back can be doing the boring stuff so you can get on with your list of awesome stuff then so be it.

For sure. Any help will be greatly appreciated. I have started the thread for it here: https://forums.ldraw.org/thread-25492.html 
My method for fixing these rounding errors is described in the first post. For detection of rounding errors, I host the buildinginstructions.js project locally and use this page: https://github.com/LasseD/buildinginstru...rators.htm

I had made an automated tool for finding the misaligned points within a part file... which unfortunately got lost when I forgot to push the git branch it belonged to. I want to build a new one, and perhaps even a tool that automatically fixes these point misalignments, but it will take some time to make sure that it doesn't overcorrect or make other unwanted changes.