adwind

Adding prints to Studio 2.0

Recommended Posts

Hi everyone! I wasn't able to find the answer on this, so I created this topic. 

I was looking for a simple way to add prints (existing or custom) in Studio 2.0 

For example I was trying to find this body print 973pb2834c01, but it's not there...

Thank you for any advice! 

Share this post


Link to post
Share on other sites

Short answer, I don't think it's possible yet (many have asked), that is, if you want bitmap textures.

Long(er) answer, it's possible but very complicated & requires vector prints (not even in common formats like SVG, that'd be too simple).

Edited by anothergol

Share this post


Link to post
Share on other sites

Several people have asked for a capability of having 'backgrounds' this would be the same thing. if they gave us the capability for adding images to three sides and the 'ground' it would make a lot of people happy.

 

Share this post


Link to post
Share on other sites

I am working on a way to make this work using SVG files and custom parts. This 'PRO' sticker is from a PNG file and the render is from Stud.io 2.0 with the latest update:

bYXISDG.png

To get from PNG to SVG I used https://www.autotracer.org 

To get from SVG to LDraw I am working on the new project svg2ldraw: https://github.com/LasseD/svg2ldraw

To get the part into stud.io 2.0 I use the CustomParts folder.

 

Currently the project can only handle a small subset of the SVG specification - just enough for the output generated by Autotracer. This is the best method I could come up with for now. 

 

Share this post


Link to post
Share on other sites

You are welcome. I have just added support for SVG rectangles, groups, and circles, so it can read even more SVG files which are created using inkscape. This allowed me to use the SVG files for Chevrolet and Corvette logos from Wikipedia in order to achieve this:

224.png

I have hosted the app for converting SVG files here: https://c-mt.dk/software/svg2ldraw/

The car can be seen 'live' with building instructions and parts list here: https://brickhub.org/i/224

The app is still under development. As an example it doesn't currently show error messages to the user when it encounters SVG features it doesn't know If you find any unsupported you would like me to add (I think there are more than 100 details in the spec!) then don't hesitate to reach out.

Share this post


Link to post
Share on other sites

@Lasse DNice work!

I tried your converter page with a minifig face svg but unfortunately it didn't work at all on my file (the LDraw field remains empty). Granted, I made the svg with Corel Draw, but even after loading it in Inkskape and saving it again, it still didn't work. The file I tried is here: http://www.brickshelf.com/gallery/Philo/Decals/face.svg

Edited by Philo

Share this post


Link to post
Share on other sites

Now that's what I'm talking about. That is an excellent test file!

It has 4 SVG features which the program couldn't handle:

- Physical size on dimensions

- Additive Bezier curves

- Implicit command conversion

- rectangles with 'stroke' instead of 'fill'.

The three first features have just been added, so the file works now. 'Stroke' will take some time to get implemented, as it requires computation of shapes around shapes... which is not an easy thing to convert to LDraw!

Share this post


Link to post
Share on other sites

I had the feeling I made nothing fancy but... Afaik the only rectangle I used is the framing one (useful to avoid cropping on bitmap export)

Share this post


Link to post
Share on other sites

If you want another svg example that partially fail... I have this one: http://www.brickshelf.com/gallery/Philo/Decals/torso-simple.svg. Again it was done with Corel Draw, and converted to "svg simple" with Inkskape.

And otherwise... do you intend to use a better triangulation? Maybe using this code: https://www.cs.cmu.edu/~quake/triangle.html (It's the library used in txt2dat).

Share this post


Link to post
Share on other sites

Thanks again for a good test file! I have added user-facing debugging information, so you can see what is going on behind the scenes. For the torso-simple.svg the following warnings appear (my comments below each):

 

fill:none; is not yet supported. SVG elements with this property will be ignored.

 

This will not be easy to implement, but I have a couple of ideas. It will be put in the back-log.

 

Unsupported SVG element type: text. This element will be ignored.

 

Ouch! This one is a toughie! Transforming text with various fonts to geometric objects is even more complicated than supporting stroke!

Crossing lines discovered in SVG file. Layered approach will be used. This issue can some times be avoided by increasing "Points per 100 pixels". Number of paths: 41

 

It is on my TODO-list to be able to handle intersections. Right now the program defaults to drawing paths at different heights in order to avoid having to compute which color to draw when intersections occur.

 

 

Self-intersections found in path 14. It will not be present in the LDraw file.Self-intersections found in path 17. It will not be present in the LDraw file.

 

(Many more like this)

Right now the program simply can't handle that a path intersects itself due to the topology not being well-defined. An issue has been raised.

 

As for triangulation, I think that it would be a step back to compute a Delauney-triangulation, rather than the current trapezoid-based decomposition. The advantage of a Delauney triangulation is the maximization of the minimal angle in a triangle, which is good for drawing. However, it comes at the cost of no longer having line types 4 in the output, and no longer be able to use the sweep-line-based framework I have made for the geometric functions. I will not be able to use their library directly due to svg2ldraw being written in JS, but I can easily make my own Delauney-triangulation if it turns out that this would be preferred.

 

You have given me a lot of work, @Philo. I work on this project in the bus between home and work, so there is enough for a couple of months in the above! :D

Edited by Lasse D
Added features.

Share this post


Link to post
Share on other sites

There seems to be a disconnect in stud.io when adding prints like this. The renders I have posted above shows nicely and in the same way as in LDView, MLCad, BrickHub, etc.

In stud.io it looks like this:

QaOfvom.png

It seems like sizing and positioning is being computed differently in their normal render compared to the 'realistic' renders.

Share this post


Link to post
Share on other sites
On 1/29/2019 at 8:18 PM, Lasse D said:

This will not be easy to implement, but I have a couple of ideas. It will be put in the back-log.

Ouch! This one is a toughie! Transforming text with various fonts to geometric objects is even more complicated than supporting stroke!

The good news is that Corel Draw allows me to easily convert strokes and text to "normal" fills...

On 1/29/2019 at 8:18 PM, Lasse D said:

It is on my TODO-list to be able to handle intersections. Right now the program defaults to drawing paths at different heights in order to avoid having to compute which color to draw when intersections occur.

Yes, I noticed that. Indeed it's a problem, as stacked surfaces is not the proper way to do this - it causes artifacts if the plane are close enough - and otherwise the stack can get high...

 

On 1/29/2019 at 8:18 PM, Lasse D said:

As for triangulation, I think that it would be a step back to compute a Delauney-triangulation

The problem I see with current approach is that it results in many, many more vertices than necessary. I can also see line artifacts, probably when the trapeziums are too narrow.

 

On 1/29/2019 at 8:18 PM, Lasse D said:

However, it comes at the cost of no longer having line types 4 in the output

Why do you see this as a problem? If needed neighboring triangles can be easily merged into quads...

On 1/29/2019 at 8:18 PM, Lasse D said:

You have given me a lot of work, @Philo. I work on this project in the bus between home and work, so there is enough for a couple of months in the above! :D

Sorry for that ;) - I'm not in a hurry anyway...

 

17 hours ago, Lasse D said:

There seems to be a disconnect in stud.io when adding prints like this. The renders I have posted above shows nicely and in the same way as in LDView, MLCad, BrickHub, etc.

Weird... can you share a file that shows the problem?

Edited by Philo

Share this post


Link to post
Share on other sites
18 hours ago, Philo said:

The good news is that Corel Draw allows me to easily convert strokes and text to "normal" fills...

Yes, I noticed that. Indeed it's a problem, as stacked surfaces is not the proper way to do this - it causes artifacts if the plane are close enough - and otherwise the stack can get high...

 

The problem I see with current approach is that it results in many, many more vertices than necessary. I can also see line artifacts, probably when the trapeziums are too narrow.

 

Why do you see this as a problem? If needed neighboring triangles can be easily merged into quads...

Sorry for that ;) - I'm not in a hurry anyway...

 

Weird... can you share a file that shows the problem?

That is indeed good news with the Corel Draw - then I don't have any reason to attack stroke before intersections.

 

My own stickers are also suffering from the stacked approach. You can even see it in the Corvette logo in the latest picture if you look closely. Yesterday I came up with a way to get this implemented properly using JS, so I will start this work once I'm in the bus Monday. It will probably take a couple of weeks to complete.

 

The problem with the many vertices is not so much the amount, as it is the thin slabs, as you point out. The Delauney triangulation will also cause additional (Steiner) vertices, but it has a more elegant way of placing them, causing fewer artifacts. Since the approach I will be using for handling intersections will cause even more additional vertices, I will have to add a 'stitching together' mechanism to the pipeline anyway. The standard "Delauney approach"  (Build a triangulation by adding lines randomly and repair the triangulation in each step to obtain Delauney) should be a good fit.

 

I saw it as a problem because I would have to make an extra step in the pipeline in order to obtain the desired result. The point is void now that I have to add this step anyway.

 

The sample file with the error has unfortunately been overwritten. It had a line similar to the following:

1 0 0 0 0 0 0 0.6 0 1 0 0.6 0 0 sticker_placed_in_custom_parts.dat

The stud.io builder scene shows the sticker in the wrong size, while all other renders were OK.

Share this post


Link to post
Share on other sites
1 hour ago, Lasse D said:

The sample file with the error has unfortunately been overwritten. It had a line similar to the following:

1 0 0 0 0 0 0 0.6 0 1 0 0.6 0 0 sticker_placed_in_custom_parts.dat

The stud.io builder scene shows the sticker in the wrong size, while all other renders were OK.

Ah - this explains. Studio doesn't know about scaling! It normalizes the transformation matrix. This is the same issue I faced here: https://forums.ldraw.org/thread-23006-post-29747.html#pid29747

Share this post


Link to post
Share on other sites

I have updated the algorithm, so it now no longer layers the triangles. It is not able to handle stroke and text, so poor Sally still doesn't look right. The decomposition has been changed from 'trapezoid' to 'general convex hull' which causes much fewer artifacts and a smaller file size.

The old algorithm handled unexpected shapes by flipping the table and storming out the door. This new one simply writes an orange warning and gives a suggestion for improving the situation.

There is one extra feature I would like to add before making a separate topic for it.

Share this post


Link to post
Share on other sites
14 hours ago, Lasse D said:

I have updated the algorithm, so it now no longer layers the triangles. It is not able to handle stroke and text, so poor Sally still doesn't look right. The decomposition has been changed from 'trapezoid' to 'general convex hull' which causes much fewer artifacts and a smaller file size.

I like that! I converted a simple file that failed previously: http://www.brickshelf.com/gallery/Philo/Decals/tail-overlap.svg. Now the problem is that there are lots of T-junctions that prevent easy further simplifications.

I also tried to improve Sally svg (converting text and strokes to shapes) and indeed I was able to get a much better result: http://www.brickshelf.com/gallery/Philo/Decals/sally2a.dat

Unfortunately I went further to get the missing elements properly converted, and now the result is no longer OK :( Here is the SVG: http://www.brickshelf.com/gallery/Philo/Decals/sally2-simple.svg (and I didn't kept the intermediate step...)

Share this post


Link to post
Share on other sites

I have updated svg2ldraw to be better at working with degenerate paths which appear when rounding to 4 decimals. It seems like 'sally2' is using CSS class to get the fill-properties. This I did honestly not expect, so right now all the output will appear in black.

Making sure that there are no T-sections is not as easy as it sounds. I will have to make a post-processor to remove these. It is on my TODO-list.

Share this post


Link to post
Share on other sites

The latest version now removes T-sections and attempts to optimize the output. I see a 5% to 30% reduction in file size after this optimization and I will spawn a separate thread for the tool once I have performed some more testing. The next big thing will be to improve performance.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.