juliageometry / descartes.jl Goto Github PK

Currently ForwardDiff does not like the use of max for set operations. There are two approaches I can think of:

• Use ADF which should give smooth approximations using the trilinear interpolations
• Implement some sort of API for requesting a Ck continuous function from FRep

This is blocking the use of DualContours on FRep

Currently, I need a rounded rectangle. It would be like the current "Square" except with a radius parameter for rounded corners.

Your current "Square" does allow rectangles, so renaming it to "Rectangle" would be another suggestion.

Originally posted by @scheming-pony in #45 (comment)

implement normals in Descartes.

julia> using Descartes
julia> using ForwardDiff
julia> p = Circle(1.0)
julia> ForwardDiff.gradient(f,[1,0])
2-element Vector{Float64}:
 1.0
 0.0

can switch to FiniteDiff if ForwardDiff/Zygote doesn't play well with max type operations

We can do this by converting primitves to FRep.

Part of implementing a hardware library.

Maybe use homogenous coordinates?

2D

• circle(radius | d=diameter)
• square(size,center)
• square([width,height],center)
• polygon([points])
• polygon([points],[paths])
• text(text, size, font, halign, valign, spacing, direction, language, script)

3D

• sphere(radius | d=diameter)
• cube(size, center)
• cube([width,depth,height], center)
• cylinder(h,r|d,center)
• cylinder(h,r1|d1,r2|d2,center)
• polyhedron(points, triangles, convexity)

Transformations

• translate([x,y,z])
• rotate([x,y,z])
• scale([x,y,z])
• resize([x,y,z],auto)
• mirror([x,y,z])
• multmatrix(m)
• color("colorname",alpha)
• color([r,g,b,a])
• offset(r|delta,chamfer)
• hull()
• minkowski()

Boolean operations

• union()
• difference()
• intersection()

Other

• import("….stl")
• linear_extrude(height,center,convexity,twist,slices,scale)
• rotate_extrude(angle,convexity)
• surface(file = "….dat",center,convexity)
• projection(cut)

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

https://github.com/sjkelly/textcad

The architecture for TextCAD was Python -> Serializer -> JSON -> Parser -> OpenSCAD.

IR fixes a alot of the current punishment on the compiler. JLD may be suitable. The upside is then Julia -> Serializer -> JLD -> GPU Ops

Somewhat related to #20

I kind of think they should default to Int and then we can define working resolution elsewhere. We need to be careful not to introduce globals during evaluation time. I think the trade off during construction is acceptable.

Hello, I'd like to evaluate FReps at a vector of inputs as follows:

julia> using Descartes

julia> c = Circle(1.0)
Circle{Float64}(1.0)

julia> x = rand(2,10);

julia> FRep(c,x[1])
-0.8388503806040237

julia> f = FRep(c,x)
1.382979664762074

I would like the final output f to be a vector of size [1,10] with f[i] = FRep(c,x[i]). Could you help me get started with implementing this?

oh no

CoordinateTransforms and GeometryBasics should be able to be composed here to reduce a lot of the code. Both have more rich types and APIs that are better than what is here.

We need polygons, squares, circles to start and close this. BSplines can come later.

This paper is relevant to designing a "unified" modeling system with different rendering back ends as your project Descartes proposes (sorry about the horrid formatting of the PDF):

http://papers.cumincad.org/data/works/att/acadia11_196.content.pdf

Not to discourage you (I like difficult challenges myself), but I think it is going to be hard in general to create a unified modeling language for all the various techniques like filleting, sweeping, etc. found in mechanical design.

Something good to investigate may be recent advancements in AD for ML. There seem to be strong parallels. One of the long term objectives here was to not only converge solid model representations but to also allow solid model representations to converge to some ideal functional objective. I.e. objective-based design. Cautious of premature optimization, in the short term I think the objectives should be simple:

• Rework the FRep system for Julia 1.0 paradigms.
• Develop some sort of useful rendering infrastructure to allow for rapid development
• Produce a useful simulation infrastructure

Those three objectives should provide solid releases checkpoints that I think most people will find useful.

On beignet with HD620 gpu:

Beignet: "unable to find good values for local_work_size[i], please provide\n" " local_work_size[] explicitly, you can find good values with\n" " trial-and-error method."

test/example001.jl will trigger this.

This is not an issue on Beignet on Sandy Bridge, presumably because it uses OpenCL -> SIMD.

Yep.

This package is well over 6 years old now! It would be good to use some more modern idioms:

• ComposedFunction
• Make shapes callable
• Avoid storing inverse transforms

Maybe even not use resolution and rather choose sample count

Maybe use something like https://github.com/timholy/HDF5.jl for caching distance fields.

jb/tupleoverhaul doesn't seem to get rid of the allocations during FRep eval. There are some deeper design issues here:

julia> u = union(Sphere(2, (2,3,4)), Sphere(4, (4,5,6)), Sphere(5, (7,8,9)))
Descartes.CSGUnion{3,Int64}(Descartes.Sphere{3,Int64}(2,(2,3,4)),Descartes.CSGUnion{3,Int64}(Descartes.Sphere{3,Int64}(4,(4,5,6)),Descartes.Sphere{3,Int64}(5,(7,8,9))))

julia> a = FRep(u)
Descartes.FRep{3,Int64}(Descartes.CSGUnion{3,Int64}(Descartes.Sphere{3,Int64}(2,(2,3,4)),Descartes.CSGUnion{3,Int64}(Descartes.Sphere{3,Int64}(4,(4,5,6)),Descartes.Sphere{3,Int64}(5,(7,8,9)))),csgunion_frep)

julia> @code_lowered a.func(1,2,3)
1-element Array{Any,1}:
 :($(Expr(:lambda, Any[:x,:y,:z], Any[Any[],Any[Any[:x,Any,0],Any[:y,Any,0],Any[:z,Any,0]],Any[Any[:u,Descartes.CSGUnion{3,Int64},1]],0], :(begin  # /home/steve/.julia/v0.4/Descartes/src/frep.jl, line 15:
        return min((FRep((top(getfield))(u,:left)::Any)::Any)(x,y,z)::Any,(FRep((top(getfield))(u,:right)::Any)::Any)(x,y,z)::Any)::Any
    end::Any))))

How could I forget? 100% coverage or bust!

So we can see things and make them.

I looked at CUDA, Vulkan, and OpenCL. It is important this runs on most hardware, so CUDA is not an option initially unless we have several backends, which is not a priority right now. Vulkan compute kernels made my eyes bleed. OpenCL might be the best option for this.

Open question and testing is whether or not to use CLArrays or OpenCL.

`using Descartes

c = Cuboid([5,5,5])

h = translate([2.5,2.5,0])Cylinder(1,5)

obj = diff(c,h)

m = HomogenousMesh(obj)

save("cube_with_hole.stl", m)`

Return: UndefVarError: HomogenousMesh not defined

My version info:
Julia Version 1.6.2
Commit 1b93d53fc4 (2021-07-14 15:36 UTC)
Platform Info:
OS: Windows (x86_64-w64-mingw32)
CPU: AMD Ryzen 5 3600X 6-Core Processor
WORD_SIZE: 64
LIBM: libopenlibm
LLVM: libLLVM-11.0.1 (ORCJIT, znver2)
Environment:
JULIA.EXECUTABLEPATH = C:\Users\USER\AppData\Local\Julia-1.3.1\bin\ & set JULIA_NUM_THREADS=12 & julia.exe
JULIA_NUM_THREADS = 12

I understand that the translation syntax mimics that of OpenSCAD, but it doesn't make any sense to me from the perspective of a (beginner) Julia programmer. How can you put two functions next to each other and not have an infix operator or have them wrapped in a function call?

CSGUnion -> union
etc...

This just needs some finesse for type stability. In the Integer case, we want to apply the transform and take the floor of the min, and ceil of the max.

I am not sure what these are technically called, but it would be nice to have them for designing nuts and screws.

• CoordinateTransformations.jl
• Remove obtuse parameterizations

This is probably a dumb question, but my knowledge of Julia is limited. I'm trying to do this code:

using Descartes                                                                                                                   
                                                                                                                                  
function create_horse_shape()                                                                                                     
    body_length = 1.0                                                                                                             
    body_width = 1/2 * body_length                                                                                                
    body_thickness = 1/12 * body_length                                                                                           
    body_cutout_circle_radius = body_length / 2                                                                                   
    body_cutout_circle =  Circle(body_cutout_circle_radius)                                                                       
end

when I run create_horse_shape I get this error:

ERROR: MethodError: no method matching Circle(::Float64)
Closest candidates are:
  Circle(::T, ::StaticArrays.SArray{Tuple{3,3},T,2,9}, ::StaticArrays.SArray{Tuple{3,3},T,2,9}) where T at /home/stewart/.julia/dev/Descartes/src/types.jl:16
Stacktrace:
 [1] create_horse_shape() at ./REPL[2]:6
 [2] top-level scope at none:0

How should I use Circle? Thanks.

DualNumbers might be and efficient way to do this.

One of the ideas behind this library was to create differentiable geometry. We need to solve Quadratic Error Functions for Dual contours (#15). In addition we may save some time by using Oct Trees, but I am unsure how these behave on the GPU and if there are known algorithms for meshing of Oct Trees.