and i do see the obj file in both directories
i just went into the configuration manager and had it create the 64 bit build configuration
sorry, i am not a cmake pro
there are options to customize this
and these scripts are provided so you can easily get the project configured
but most probably you would then use your own
@fjpietr @yzrmn Thanks for testing the variable stroke and sorry if it's caused a drift. I thought the existing stroke engine swept a normal along the path and you had an algorithm to fix tight corners? As a possible work-around, can you blend from a variable width stroke engine to the existing constant width engine as it approaches tight curves? You could define problem curves as any path point having 2 segments that form a very acute angle with short in/out tangents. As you iterate along the first segment and approach the problematic path point, interpolate between the variable width normal to a constant width normal (whatever the width should be at the problematic path point) by the time you reach 90% along the first segment. Continue using a constant width normal until you reach 10% along the next segment, then interpolate back to the variable width. Hopefully the tight corners would hide the interpolation. Sorry if my level of knowledge underestimates the problem :) just thought it might be a solution to try in the future, so don't worry about it for now :) thanks again
If I understand it correctly: to get rid of the loop/the "unfolded" loop, in the interval around the critical point adjust temporarily the width to satisfy the constraint imposed by the curvature. But I think there's a problem...while this can work and pass unnoticed in many cases, now the stroke width is governed by the curvature, not the user anymore: the user wants a quasi constant-width stroke along a very sharp tight point (in/out tangents very close), but the stroke width has to become very small to avoid self intersections or concavities in the offset curve.
Anyway if you just want to draw the path the loop is not a problem, the fill rule takes care of it. The problem is there only if you want to build an outline of it, that is, a clean non self intersecting offset curve. The "unfolded" loop (the concavity) on the other hand is a problem in both cases, because it's ugly :D
In my experiments (only concerned with drawing, not making clean offset curves) making an envelope of circles (like: ---ooOOO--- but overlapping so that each pair of circles has two intersection points) along the path and building inner and outer offset curves by constructing segments between successive intersection points seems more well behaved
even when the width envelope has cusps or fast variations
@yzrmn yes, and in fact we're all here losing sleep :D
@fjpietr That looks absolutely amazing! I like how your UI allows you to shape the thickness! Are you guys are aiming for a level of unexpected perfection? In motion graphics we don't convert animated stroked lines to outlines because of the performance hit. In Adobe Illustrator, I regularly experience imperfections upon converting stroked paths to outlines, so I simply patch them up - you simply accept it :) Provided the fill rule hides all imperfections, I think that's all a developer would expect. It would be awesome if what you've achieved was included in Blend2D. Can you also vary the width by setting a width at each path point, so basically each BLPoint has an additional stroke width parameter? Must sleep now ...but this is very exciting! thanks again
@Oldes If we had something like a 'BLStrokeType' with options BL_STROKE_TYPE_CONSTANT, BL_STROKE_TYPE_VARIABLE_SCULPTED, BL_STROKE_TYPE_VARIABLE_PERPOINT, it would allow us to choose how the stroke is rendered. Then your suggestion of a global width modifier would be scalar (1.0 = 100%) that globally effects the stroke regardless of the type, which is excellent because it saves the user iterating through all BLPoints or Sculpt Path points to globally adjust them :)
Slightly off topic, here's something from a few years back that you might find interesting in the future. It details a method that allows tidier deformation of cubic bezier splines. I doubt it applies to the perspective deformation (listed on roadmap), but if you consider adding a deformation method similar to AE 'puppet-pin', the info in this paper would definitely yield better results than standard linear fall off. AE rasterizes the artwork when 'puppet-pin' is enabled which sucks because you can't zoom unless your artwork is very high resolution, which in turns slows down performance. Have a quick read when you get chance, perhaps the algorithms are useful for something else :)
different topic: Has anyone done any work with wasm/wasi and blend2d?
I'm thinking there's a viable runtime environment lurking in a nanos/wasm/blend2d combination
I’m not sure what B2D could offer here? I mean you have a web-browser with ton of stuff you can access, it has all the drawing primitives IIRC. Of course not so cool as B2D but well… browser apps are not cool anyway :-)
Or do you mean WASM without a browser?
I just about have blend working with SFML but have run into an issue where the flush command does not seem to be working like I would expect. I basically do my blend drawing then call ctx.flush(BL_CONTEXT_FLUSH_SYNC); before updating the texture and blitting. The scene is not draw correctly. My reference example is bl-getting-started-8.cpp, It basically only shows the last line of text. If I call ctx.end() before updating the texture instead of flush() everything works as expected. What is flush() supposed to do?
sorry, thought I uploaded the PDF,, here's a link to it http://www.cs.toronto.edu/~jacobson/images/skinning-cubic-bezier-splines-and-catmull-clark-subdivision-surfaces-siggraph-asia-2014-liu-et-al.pdf enjoy :)
@RallyTronics
ctx.flush(BL_CONTEXT_FLUSH_SYNC); does nothing at the moment. The function will only make sense when the asynchronous (read multithreaded) rendering is implemented - then there will be flush (aka flush command buffer) with either SYNC or ASYNC option - ASYNC would mean to make a notification after the last rendering command has completed, SYNC would mean to wait (aka BLOCK) until the last rendering command has completed
At the moment Blend2D does synchronous rendering, which means that every render command completes and then returns, so you can basically see the result immediately
Think like Java but browsers may execute them as well :)