juliageometry / geometrytypes.jl Goto Github PK

Maybe you're are still setting things up ;)

I get a StackOverflowError with the following code using Julia v0.5

julia> using GeometryTypes
julia> large_sphere = HyperSphere(Point3f0(0), 1f0)
GeometryTypes.HyperSphere{3,Float32}(FixedSizeArrays.Point{3,Float32}((0.0f0,0.0f0,0.0f0)),1.0f0)
julia> decompose(Point3f0, large_sphere)
ERROR: StackOverflowError:
 in decompose at /home/blegat/.julia/v0.5/GeometryTypes/src/decompose.jl:5 (repeats 26665 times)

This is taken from this example: http://simondanisch.github.io/lines/linesegments3d/

See comments in #33. Specifically HyperCube allows each interval to be of different length, which goes against the hyper geometry definition.

Since changing HyperCube itself is not enough work (:P), I propose switching from specifying intervals with start and end points in HyperRectangle to the approach in HyperCube.

This is the proposed change:
From:

immutable HyperRectangle{N, T} <: GeometryPrimitive{N}
    minimum::Vec{N, T}
    maximum::Vec{N, T}
end
immutable HyperCube{N, T} <: GeometryPrimitive{N}
    origin::Vec{N, T}
    width::Vec{N, T}
end

To:

immutable HyperRectangle{N, T} <: GeometryPrimitive{N}
    origin::Vec{N, T}
    widths::Vec{N, T}
end
immutable HyperCube{N, T} <: GeometryPrimitive{N}
    origin::Vec{N, T}
    width::T
end

This can be seen when rendering in GLVisualize

code:

using GLVisualize,GeometryTypes,ColorTypes
window = glscreen()
C = Cylinder3{Float32}([-1,-1,-1],[1,1,1],1)
_view(visualize(GLNormalMesh(C,100),color = RGBA{Float32}(1,0,0,1)))
renderloop(window)

the inside is brighter than the outside

I've been playing with the meshing algorithms implemented in the Meshes.jl family, and they've been extremely helpful! But I noticed that the vertices of the meshes returned by marching cubes and marching tetrahedra are in an odd choice of coordinate system. As far as I can tell, the vertex coordinates are in the range [1, size(sdf)], mapping to the world-coordinate bounds of the field. While I can certainly undo that mapping to get world coordinates out, it seems like a somewhat strange choice.

Since the SignedDistanceField stores its world-coordinate bounds, it would be possible to have the meshing algorithms return world coordinate vertices, which seems to me to impose less burden on the user.

First, is this behavior intentional? Or is it a bug? If it's a bug, I'm happy to try to fix it.

For reference, the code I'm running to observe this behavior is:

using Meshes
using GeometryTypes

s = SignedDistanceField(HyperRectangle(Vec(0,0,0.),Vec(1,1,1.))) do v
           sqrt(sum(dot(v,v))) - 1 # sphere
       end
m = HomogenousMesh(s) # uses Marching Tetrahedra from Meshing.jl
vertices(m)

973-element Array{FixedSizeArrays.Point{3,Float64},1}:
 Point(6.0,9.0,4.289259971769505)                              
 Point(10.759636704703446,1.759636704703446,3.0)               
 Point(6.0,8.0,6.093133249283693)                              
 Point(6.0,8.782712686772829,4.782712686772829)   
...

There are a few surprises (at least to me) that can happen with broadcasted Point arithmetic:

julia> [Point(1,1), Point(2,2), Point(3,3)] .- Point(1,-1)
ERROR: DimensionMismatch("arrays could not be broadcast to a common size")

julia> [Point(1,1), Point(2,2)] .- Point(1,-1)
2-element Array{Point{2,Int64},1}:
 [0, 0]
 [3, 3]

I would have instead expected:

julia> [Point(1,1), Point(2,2), Point(3,3)] .- Point(1,-1)
3-element Array{Point{2,Int64},1}:
 [0, 2]
 [1, 3]
 [2, 4]

julia> [Point(1,1), Point(2,2)] .- Point(1,-1)
2-element Array{Point{2,Int64},1}:
 [0, 2]
 [1, 3]

One possible fix on julia 0.7 is to define something like:

for f in (:+, :-)
    @eval Broadcast.broadcasted(::typeof($f), a::AbstractArray, p::Point) =
        Broadcast.broadcasted($f, a, StaticArrays.Scalar{typeof(p)}((p,)))
    @eval Broadcast.broadcasted(::typeof($f), p::Point, a::AbstractArray) =
        Broadcast.broadcasted($f, StaticArrays.Scalar{typeof(p)}((p,)), a)
end

Though I haven't thought through the broader implications, this is how I'm getting around the problem in a package I have that defines its own Point types. I'd much rather use the Point type defined here so that I can have compatibility with your visualization packages.

The line segments intersect, but the intersects predicate returns false.

julia> s1 = LineSegment(GeometryTypes.Point{2,Float64}[[0.88033, 1.28211], [3.525, 1.28211]]...);

julia> s2 = LineSegment(GeometryTypes.Point{2,Float64}[[2.0375, 1.1625], [2.0375, 1.2875]]...);

julia> GeometryTypes.intersects(s1, s2)
(false, [0.0, 0.0])

I didn't look into the bug, but for now I'm using the following intersection method

using GeometryTypes
module GG
using StaticArrays
function param_seg(seg, t)
    p = seg[1]
    v = seg[2] - seg[1]
    return p + t * v
end

function intersects_sys(seg1, seg2)
    p1 = seg1[1]
    p2 = seg2[1]
    v1 = seg1[2] - seg1[1]
    v2 = seg2[2] - seg2[1]

    # solve p1 + v1*t1 = p2 + v2*t2

    A = @SMatrix [
        v1[1]  -v2[1] ;
        v1[2]  -v2[2] ]
    b = SVector(p2 - p1)
    return (A,b)
end

function intersects(seg1, seg2)
    (A, b) = intersects_sys(seg1, seg2)
    ts = A \ b
    return all(0.0 .≤  ts .≤ 1.0)
end
end

julia> GG.intersects(s1, s2)
true

All hail the ominous sphere. I am working on this one.

@SimonDanisch I am confused about the purposed of the Quad type in the current type hierarchy. I looked at the use in GLVisualize, and it seems to be used as a coordinate system or alignment for cameras. Can you explain the intention of this?

Hey Simon,

Would you mind telling me exactly what the fields are supposed to be in the Cube and the Pyramid primitives? I just want to make sure I'm setting them correctly in Compose3D.

Regards,
Rohit.

Trying to e.g. add a Point to a Normal produces a StackOverflowError:

using GeometryTypes
Point{2, Float64}(0) + Normal{2, Float64}(0)

LoadError: StackOverflowError:
while loading In[3], in expression starting on line 1

 in + at /home/rdeits/.julia/v0.4/FixedSizeArrays/src/ops.jl:64 (repeats 513 times)

Should this operation work, or should it throw an error in GeometryTypes?

Hello,

it will be nice to have doc published to Github pages http://juliageometry.github.io/GeometryTypes.jl/latest

Most Julia package are using Documenter.jl not Docile.jl which doesn't seem to be maintained anymore.

Kind regards

In the Julia v0.5 version, I could do:

M = GLNormalMesh
V = vertextype(M)
F = facetype(M)
vs = [V(0., 0, 0), V(1., 0, 0), V(0., 1, 0)]
fs = [F(1, 2, 3)]
GLNormalMesh(vs, fs)

but in GeometryTypes master, that now throws:

MethodError: Cannot `convert` an object of type GeometryTypes.HomogenousMesh{GeometryTypes.Point{3,Float32},GeometryTypes.Face{3,GeometryTypes.OffsetInteger{1,UInt32}},Void,Void,Void,Void,Void} to an object of type GeometryTypes.HomogenousMesh{GeometryTypes.Point{3,Float32},GeometryTypes.Face{3,GeometryTypes.OffsetInteger{1,UInt32}},GeometryTypes.Normal{3,Float32},Void,Void,Void,Void}
This may have arisen from a call to the constructor GeometryTypes.HomogenousMesh{GeometryTypes.Point{3,Float32},GeometryTypes.Face{3,GeometryTypes.OffsetInteger{1,UInt32}},GeometryTypes.Normal{3,Float32},Void,Void,Void,Void}(...),
since type constructors fall back to convert methods.

Stacktrace:
 [1] GeometryTypes.HomogenousMesh{GeometryTypes.Point{3,Float32},GeometryTypes.Face{3,GeometryTypes.OffsetInteger{1,UInt32}},GeometryTypes.Normal{3,Float32},Void,Void,Void,Void}(::Array{GeometryTypes.Point{3,Float32},1}, ::Array{GeometryTypes.Face{3,GeometryTypes.OffsetInteger{1,UInt32}},1}) at /Users/rdeits/.julia/v0.6/GeometryTypes/src/meshes.jl:107

It seems like some FixedSizeArray exports are re-exported by this package. I don't think this is
necessarily a problem now, but it might be in the future if we want to change vector backends.

CC @SimonDanisch

In Julia v0.6, there is the following error in precompilation

ERROR: LoadError: LoadError: invalid subtyping in definition of AbstractMesh
Stacktrace:
(...)
while loading /home/travis/.julia/v0.6/GeometryTypes/src/types.jl, in expression starting on line 9

This line is:

abstract AbstractMesh{VertT, FaceT} <: AbstractGeometry

The errors seems to be that AbstractGeometry has the parameters {N, T} an now in Julia v0.6, you cannot subtype a type without specifying all parameters.

Heads up - I was thinking that Julia v0.7 might be a good time to add a deprecation to the StaticArrays.FixedSizeArrays module, for removal in Julia v1.0.

I noticed this package still uses that module. See JuliaArrays/StaticArrays.jl#459

Would this package be a good place to implement homogeneous coordinates? I'd quite like to migrate my 3D Geometry work away from my home-grown Points to GeometryTypes Points, but I need homogeneous coordinates. I might be able to implement this myself, but I'm facing a looming thesis deadline, and wary of promising anything to anyone, sadly.

I've been thinking about some kind of low level/ intermediate representation for geometry lately to have a good way to switch out frontends and backends without much hassle. This is pretty much what I've come up with after working with Compose, GLVisualize and FireRender. They all differ hugely, but it seemed to me that they could all support the same intermediate representation.

This representation needs a great deal of flexibility, since we don't want to force any frontend/backend to miss out on compression/batching or force them to use one specific memory layout.
To not go crazy over the resulting diversity, I'd like to propose the following:

I want to use something like an extended version of @simonster's StructsOfArrays library (with added support for iterators, scalars and different memory layouts) to allow for the kind of compression and memory layout independence that GLVisualize and Compose already offer in some restricted form.

A few examples:

SOA = StructsOfArrays
# A thousand circles spreaded evenly on the x axis  with minimal memory usage:
xposition = 1:1000
yposition = 0
radius = 1
# this might remind you of Composes's circle([0.25, 0.5, 0.75], [0.25, 0.5, 0.75], [0.1])
circles = SOA(Circle, xposition, yposition, radius) 
circles[100] == Circle(Point2f0(100,0), 1)

# Now a different memory layout (Maybe we got it from some sensor and we don't
# want to copy millions of circles just because of different memory layout, do we?)
xypositions = rand(Point2f0, 10^6)
circles = SOA(Circle, xypositions, radius)

# this can be extended to all kind of objects
x,y = linspace(0,10,100), rand(100)
lines = SAO(Line{Point}, x, y)

# or a simple representation of particles
immutable Instance{P
primitive::P
translation::Vec3f0
scale::Vec3f0
rotation::Quaternion
end

cube = Cube(Vec3f0(0),1f0) #unit cube
# Cubes on random positions
SOA(Instance, cube, rand(Vec3f0, 1000), Vec3f0(0.01), Quaternion(1,0,0,0))
x,y,z = rand(Float32, 10), rand(Float32, 10), rand(Float32, 10)
# the same, but different memory layout
SOA(Instance, cube, x,y,z, Vec3f0(1), Quaternion(1,0,0,0))
grid = Grid(linspace(0,1,100), linspace(0,1,100))
#100*100 particles with varying z scale on a grid
SOA(Instance, grid, 0,0, rand(Float32, 100, 100), Quaternion(1,0,0,0))

#GLVisualize's particle system actually partly supports this kind of batching and memory compression

#The same can be applied to materials:
immutable Material{S, C, Refl, Refr}
shader::S
color::T
reflectance::Refl
refraction::Refr
end
SOA(Material, Phong, rand(RGBA, 10), RGB(1,1,1), 1.5)


# and finally something like this:
immutable Drawable{G, M, T}
geometry::G
material::M
translation::T
end
SAO(Drawable, ....)
# With this, we could also better separate mesh geometry from the material properties.

# note, that we could represent even odd geometries like volumes and units like mm:
geometry = Cube(Vec{3, mm}(0), Vec{3, mm}(1.75, 1.2, 2.7) )
material = VolumeMaterial(image3D, absorption)
Drawable(geometry, material)

With clever conversion and defaults for unsupported attributes, this can represent everything we might want to visualize.
There will be annoying corner cases like pointed lines, where it's not really clear if the points are a geometry attribute or part of the shader. But I'm pretty sure that we'll be able to solve this in a coherent way.

Benefits

All the algorithms can work on this representation, making it way easier to reuse them in all the different packages. E.g. the implementation of a boundingbox algorithm could look as simple as this:

mapreduce(BoundingBox, union, some_sao) # obviously, BoundingBox has to be implemented for the primitive
# this could work with any of the geometry created in the examples above

In theory, this should also work on the GPU. So whenever we get better GPU support e.g. being able to compile Julia to SPIR-V, the data structures and algorithms should map nicely to the GPU.

It will be easier to display graphics created with e.g. Gadfly, Compose, GLVisualize in any backend like OpenGL, Cairo, Skia, SVG, FireRender, WebGL, PDF, as long as they support this intermediate representation.
I've already implemented quite a bit for OpenGL and FireRender and it shouldn't take too much time to add WebGL via Threejs.jl (if the package is in a good state).

Challenges

I'm not sure how to incorporate Animations. With Reactive there are two ways to do so, which I find both unsatisfactory.

width_signal = Signal(rand(Vec3f0, 10^6)
position_signal = Signal(rand(Vec3f0, 10^6)

option1 = map(SAO, Cube, scale_signal, width_signal)
-> Signal{SAO{Cube, Vec3f0, Vec3f0}}

option2 = SAO(Cube, scale_signal, width_signal)
-> SAO{Cube, Signal{Vec3f0}, Signal{Vec3f0}}

Option1 is way cleaner, as you can easily apply algorithms to it via map.
Option2 doesn't really allow to operate on the resulting SAO without some hackage.
But I'm not really sure how to make option1 fast on the backend side in all cases. If you let the signal get bigger and bigger, it's not entirely clear how to detect what has changed anymore, which means it's more difficult to only update part of the scene (which is an important optimization).
@shashi gets around this by diffing, but for big data-sets this still introduce a non trivial performance penalty. Since this is supposed to be a low level representation, it would be nice to not have such penalties early on.

Also, this must be implemented ;) I've working prototypes for most of this, so I'd be willing to start this off! Maybe, by adding WebGL support to GLVisualize.

Please criticize freely :)

Best,
Simon

CC: @sjkelly, @KristofferC, @rohitvarkey, @tbreloff, @ViralBShah, @timholy, @dcjones, @vchuravy

This might be an impetus for the getindex to call transition.

julia> using GeometryTypes

julia> typealias Vec3 Vec{3, Float32}
FixedSizeArrays.Vec{3,Float32}

julia> begin
        dirlen  = 1f0
        baselen = 0.02f0
        mesh    = [
            Cube{Float32}(Vec3(baselen), Vec3(dirlen, baselen, baselen)), 
            Cube{Float32}(Vec3(baselen), Vec3(baselen, dirlen, baselen)), 
            Cube{Float32}(Vec3(baselen), Vec3(baselen, baselen, dirlen))
        ]
        mesh = merge(map(GLPlainMesh, mesh))
       end
ERROR: BoundsError: attempt to access nothing
  at index [1]
 in append_any at ./essentials.jl:127
 in convert at /home/steve/.julia/v0.4/GeometryTypes/src/faces.jl:25
 in getindex at array.jl:167
 in getindex at /home/steve/.julia/v0.4/GeometryTypes/src/primitives.jl:24
 in convert at /home/steve/.julia/v0.4/GeometryTypes/src/meshtypes.jl:46
 in map at abstractarray.jl:1308
 in convert at /home/steve/.julia/v0.4/GeometryTypes/src/primitives.jl:15
 in map at abstractarray.jl:1308

I wanted to define a polygon. Looking through the source, I thought something like

hex_vertices = [Point2f0(1,0),
    Point2f0(cos(pi/3),-sin(pi/3)),
    Point2f0(-cos(pi/3),-sin(pi/3)),
    Point2f0(-1,0),
    Point2f0(-cos(pi/3),sin(pi/3)),
    Point2f0(cos(pi/3),sin(pi/3))]

hex_mesh = GLNormalMesh(hex_vertices)

would work. Alas it throws an error

MethodError: no method matching _default(::Tuple{Array{GeometryTypes.Point{3,Float32},1},Array{GeometryTypes.Point{3,Float32},1}}, ::GLAbstraction.Style{:default}, ::Dict{Symbol,Any})
Closest candidates are:
  _default(::GeometryTypes.HomogenousMesh{GeometryTypes.Point{3,Float32},GeometryTypes.Face{3,GeometryTypes.OffsetInteger{-1,UInt32}},GeometryTypes.Normal{3,Float32},Void,ColorTypes.RGBA{Float32},Void,Void}, ::GLAbstraction.Style, ::Dict) at C:\Users\stephan\.julia\v0.6\GLVisualize\src\visualize\mesh.jl:41
  _default(::Union{Array{GeometryTypes.Simplex{2,T<:GeometryTypes.Point},1}, GLAbstraction.GPUArray{GeometryTypes.Simplex{2,T<:GeometryTypes.Point},1}, Reactive.Signal{Array{GeometryTypes.Simplex{2,T<:GeometryTypes.Point},1}}}, ::GLAbstraction.Style, ::Dict) where T<:GeometryTypes.Point at C:\Users\stephan\.julia\v0.6\GLVisualize\src\visualize\lines.jl:107
  _default(::Union{Array{T<:Union{AbstractFloat, ColorTypes.Gray, GLVisualize.Intensity},3}, GLAbstraction.GPUArray{T<:Union{AbstractFloat, ColorTypes.Gray, GLVisualize.Intensity},3}, Reactive.Signal{Array{T<:Union{AbstractFloat, ColorTypes.Gray, GLVisualize.Intensity},3}}}, ::GLAbstraction.Style, ::Dict) where T<:Union{AbstractFloat, ColorTypes.Gray, GLVisualize.Intensity} at C:\Users\stephan\.julia\v0.6\GLVisualize\src\visualize\image_like.jl:236
  ...

Stacktrace:
 [1] default(::Any, ::Any, ::Any) at C:\Users\stephan\.julia\v0.6\GLVisualize\src\visualize_interface.jl:4
 [2] visualize(::Any, ::GLAbstraction.Style{:default}, ::Dict{Symbol,Any}) at C:\Users\stephan\.julia\v0.6\GLVisualize\src\visualize_interface.jl:21
 [3] visualize(::Any, ::Symbol) at C:\Users\stephan\.julia\v0.6\GLVisualize\src\visualize_interface.jl:20 (repeats 2 times)
 [4] include_string(::String, ::String) at .\loading.jl:522

which traces back to the fact that area(::AbstractArray{Point}) as called from polygon2faces returns a vector rather than a number.

Is the functionality broken, or am I misunderstanding how to specify a polygon?`

Many thanks for all your hard work!

How is this being done currently? In Descartes I need the forward and inverse transforms, and for simplicity I store both like below:

type Cuboid{T} <: AbstractPrimitive{3, T}
    dimensions::Vector{T}
    transform::Matrix{Float64}
    inv_transform::Matrix{Float64}
end

I think we could use @timholy 's AffineTranforms here to store this data and add an FSA interface rather than using Base.Matrix

I got partway through writing a .dae file decoder for a robotics project when I started wondering what type to use to store the result. The problem is that we currently assume (in MeshIO and in this package) that the mesh you get from a file is basically always exactly one HomogenousMesh. But what about meshes with textures or material properties? We don't really have a type that encompasses those.

In MeshCat, I have the notion of an Object, which contains a Material and a Geometry, where that geometry could be a HomogenousMesh. Would something like that be useful in GeometryTypes? Or should the mesh type be expanded to allow things like textures or material properties?

I'm trying to translate some code to the new Face & OffsetInteger types, but I'm not sure that indexing is working properly. In the old v0.5 version of GeometryTypes, I could do:

julia> f = Face{3, Int, 1}(2, 2, 2)
Face(2,2,2)

julia> x = [1, 2, 3]
3-element Array{Int64,1}:
 1
 2
 3

julia> x[f]
(1,1,1)

I think the equivalent code in master would be:

julia> f = Face{3, OffsetInteger{1, Int}}(2, 2, 2)
3-element GeometryTypes.Face{3,GeometryTypes.OffsetInteger{1,Int64}}:
 |2-1|
 |2-1|
 |2-1|

but I get a different result:

julia> x[f]
(2, 2, 2)

Likewise, indexing with a single OffsetInteger also seems to ignore the offset:

julia> x = [1, 2, 3];

julia> x[OffsetInteger{1, Int}(2)]
2

julia> x[OffsetInteger{-1, Int}(2)]
2

or is that now how the OffsetInteger type works?

There seems to be a bug in the line intersect code.

A specific failure case is

using GeometryTypes
l = LineSegment(Point(6.0,11), Point(12.0,11))

r1 = GeometryTypes.LineSegment( Point(9.0,10.0), Point(9.0, 13.0))
r2 = GeometryTypes.LineSegment( Point(9.34365, 10.890), Point(9.34365, 13.402))

julia> intersects(l, r1)
(true, [9.0, 11.0])

julia> intersects(l, r2)
(false, [0.0, 0.0])

I would expect that the second case would return true as well.

I wanted to refactor the mesh type long ago in GeometryTypes, and now that I'm working on propper FEM integration into Makie it becomes even more relevant to rethink the mesh representation.

My current thinking is, that at the core one has a set of nodes (vertices) and a vector of cells (faces) that connect those nodes. This can be represented as view(nodes, faces), since the faces do actually represent a view into those nodes. Like this, going from a e.g. tedrahedron to a visualizable surface mesh is just a matter of changing the face type.

So why should this part of the FEM infrastructure live in GeometryTypes and what will be the advantage?
Well, everything graphic related works pretty nicely with GeometryTypes.
I have a decompose infrastructure in place, which supports decomposing arbitrary geometries into its components.
E.g., this makes it very easy to visualize all kind of wireframes, meshes etc, since I can just do:

scatter(x::GeometryPrimitive) = scatter(decompose(Point, x)) # decomposes it into its positions
# extract positions and 2 segment connections between those points
wireframe(x::GeometryPrimitive) = lines(view(decompose(Point, x), decompose(Face{2, Int}, x)))
# creates a mesh with normals for shading
mesh(x::GeometryPrimitive) = mesh(Mesh(decompose(Point, x), decompose(Face{3, Int}, x), decompose(Normal, x))

Node, that decompose(Face{3, Int}, polygonmesh) already works to triangulates meshes with arbitrary faces.
So the Makie recipes could just live in GeometryTypes and work across all meshing/fem packages.

This discussion becomes more relevant, since I just made a big step forward in making Tetgen available as a package, so I expect to use advanced meshing a lot more in the future:
JuliaGeometry/TetGen.jl#7

The problem with the use of view as above is, that node[face] == NTuple{N, Node}, since one face/cell connects multiple nodes.
But in principle, that's most of what we need to represent a mesh. If we want more attributes per node, we can put them into the node type.
I wonder if we should pirate the meaning of view, or just have something like:

struct Mesh{T, N} <: AbstractVector{NTuple{N, T}}
nodes::Vector{T}
cells::Vector{Cell{N}}
end
mesh(nodes, cells) = Mesh(nodes, cells)

We might want to define the node type like this, to contain arbitrary attributes:

struct Node{T <: NamedTuple}
data::T
end
Node((color = RGB(0,0,0), position = Point(0, 1, 2), displacement = 0.0))

The above would work nicely with a trait system!
The beauty is, we won't need to pin down the Node/Vertex type right away, and should just be able to keep using already present structures and slowly converge to one representation.

What does everyon think about this? Ready to move some fem meshing types into GeometryTypes?

Best,
Simon

CC: @KristofferC, @ChrisRackauckas , @louisponet, @Kevin-Mattheus-Moerman, @mohamed82008

Here is what I get on Julia v0.6-rc3 with GeometryTypes master (i.e. at 1075b60) and Iterators v0.3.1 when I do not do using Iterators before doing using GeometryTypes.

julia> using GeometryTypes
INFO: Recompiling stale cache file /home/blegat/.julia/lib/v0.6/GeometryTypes.ji for module GeometryTypes.
WARNING: The call to compilecache failed to create a usable precompiled cache file for module GeometryTypes. Got:
WARNING: Module Iterators uuid did not match cache file.
ERROR: LoadError: Declaring __precompile__(true) is only allowed in module files being imported.
Stacktrace:
 [1] __precompile__(::Bool) at ./loading.jl:335
 [2] __precompile__() at ./loading.jl:331
 [3] include_from_node1(::String) at ./loading.jl:569
 [4] eval(::Module, ::Any) at ./boot.jl:235
 [5] _require(::Symbol) at ./loading.jl:483
 [6] require(::Symbol) at ./loading.jl:398
while loading /home/blegat/.julia/v0.6/GeometryTypes/src/GeometryTypes.jl, in expression starting on line 1

If I first do using Iterators it works but it complains that Iterators overwrites stuff in module Main but it works

julia> using Iterators
WARNING: imported binding for Iterators overwritten in module Main

julia> using GeometryTypes

On 0.6, I get

INFO: Precompiling module GeometryTypes.

WARNING: deprecated syntax "abstract Functor{N}" at /Users/michael/.julia/v0.6/FixedSizeArrays/src/FixedSizeArrays.jl:23.
Use "abstract type Functor{N} end" instead.

WARNING: deprecated syntax "abstract FixedArray{T,NDim,SIZE}" at /Users/michael/.julia/v0.6/FixedSizeArrays/src/core.jl:2.
Use "abstract type FixedArray{T,NDim,SIZE} end" instead.

WARNING: deprecated syntax "abstract MutableFixedArray{T,NDim,SIZE}<:FixedArray{T,NDim,SIZE}" at /Users/michael/.julia/v0.6/FixedSizeArrays/src/core.jl:3.
Use "abstract type MutableFixedArray{T,NDim,SIZE}<:FixedArray{T,NDim,SIZE} end" instead.

WARNING: deprecated syntax "typealias MutableFixedVector{T,CARDINALITY} MutableFixedArray{T,1,Tuple{CARDINALITY}}" at /Users/michael/.julia/v0.6/FixedSizeArrays/src/core.jl:5.
Use "MutableFixedVector{T,CARDINALITY} = MutableFixedArray{T,1,Tuple{CARDINALITY}}" instead.

WARNING: deprecated syntax "typealias MutableFixedMatrix{T,M,N} MutableFixedArray{T,2,Tuple{M,N}}" at /Users/michael/.julia/v0.6/FixedSizeArrays/src/core.jl:6.
Use "MutableFixedMatrix{T,M,N} = MutableFixedArray{T,2,Tuple{M,N}}" instead.

WARNING: deprecated syntax "typealias FixedVector{CARDINALITY,T} FixedArray{T,1,Tuple{CARDINALITY}}" at /Users/michael/.julia/v0.6/FixedSizeArrays/src/core.jl:8.
Use "FixedVector{CARDINALITY,T} = FixedArray{T,1,Tuple{CARDINALITY}}" instead.

WARNING: deprecated syntax "typealias FixedMatrix{Row,Column,T} FixedArray{T,2,Tuple{Row,Column}}" at /Users/michael/.julia/v0.6/FixedSizeArrays/src/core.jl:9.
Use "FixedMatrix{Row,Column,T} = FixedArray{T,2,Tuple{Row,Column}}" instead.

WARNING: deprecated syntax "abstract FixedVectorNoTuple{CARDINALITY,T}<:FixedVector{CARDINALITY,T}" at /Users/michael/.julia/v0.6/FixedSizeArrays/src/core.jl:11.
Use "abstract type FixedVectorNoTuple{CARDINALITY,T}<:FixedVector{CARDINALITY,T} end" instead.
WARNING: Base.linearindexing is deprecated, use Base.IndexStyle instead.
  likely near /Users/michael/.julia/v0.6/FixedSizeArrays/src/destructure.jl:13
WARNING: Base.linearindexing is deprecated, use Base.IndexStyle instead.
  likely near /Users/michael/.julia/v0.6/FixedSizeArrays/src/destructure.jl:13

WARNING: deprecated syntax "function .+(...)".
Use "function Base.broadcast(::typeof(+), ...)" instead.

WARNING: deprecated syntax "function .+(...)".
Use "function Base.broadcast(::typeof(+), ...)" instead.

WARNING: deprecated syntax "function .+(...)".
Use "function Base.broadcast(::typeof(+), ...)" instead.

WARNING: deprecated syntax "function .+(...)".
Use "function Base.broadcast(::typeof(+), ...)" instead.

WARNING: deprecated syntax "function .+(...)".
Use "function Base.broadcast(::typeof(+), ...)" instead.

WARNING: deprecated syntax "function .-(...)".
Use "function Base.broadcast(::typeof(-), ...)" instead.

WARNING: deprecated syntax "function .-(...)".
Use "function Base.broadcast(::typeof(-), ...)" instead.

WARNING: deprecated syntax "function .-(...)".
Use "function Base.broadcast(::typeof(-), ...)" instead.

WARNING: deprecated syntax "function .-(...)".
Use "function Base.broadcast(::typeof(-), ...)" instead.

WARNING: deprecated syntax "function .-(...)".
Use "function Base.broadcast(::typeof(-), ...)" instead.

WARNING: deprecated syntax "function .*(...)".
Use "function Base.broadcast(::typeof(*), ...)" instead.

WARNING: deprecated syntax "function .*(...)".
Use "function Base.broadcast(::typeof(*), ...)" instead.

WARNING: deprecated syntax "function .*(...)".
Use "function Base.broadcast(::typeof(*), ...)" instead.

WARNING: deprecated syntax "function .*(...)".
Use "function Base.broadcast(::typeof(*), ...)" instead.

WARNING: deprecated syntax "function .*(...)".
Use "function Base.broadcast(::typeof(*), ...)" instead.

WARNING: deprecated syntax "function ./(...)".
Use "function Base.broadcast(::typeof(/), ...)" instead.

WARNING: deprecated syntax "function ./(...)".
Use "function Base.broadcast(::typeof(/), ...)" instead.

WARNING: deprecated syntax "function ./(...)".
Use "function Base.broadcast(::typeof(/), ...)" instead.

WARNING: deprecated syntax "function ./(...)".
Use "function Base.broadcast(::typeof(/), ...)" instead.

WARNING: deprecated syntax "function ./(...)".
Use "function Base.broadcast(::typeof(/), ...)" instead.

WARNING: deprecated syntax "function .\(...)".
Use "function Base.broadcast(::typeof(\), ...)" instead.

WARNING: deprecated syntax "function .\(...)".
Use "function Base.broadcast(::typeof(\), ...)" instead.

WARNING: deprecated syntax "function .\(...)".
Use "function Base.broadcast(::typeof(\), ...)" instead.

WARNING: deprecated syntax "function .\(...)".
Use "function Base.broadcast(::typeof(\), ...)" instead.

WARNING: deprecated syntax "function .\(...)".
Use "function Base.broadcast(::typeof(\), ...)" instead.

WARNING: deprecated syntax "function .^(...)".
Use "function Base.broadcast(::typeof(^), ...)" instead.

WARNING: deprecated syntax "function .^(...)".
Use "function Base.broadcast(::typeof(^), ...)" instead.

WARNING: deprecated syntax "function .^(...)".
Use "function Base.broadcast(::typeof(^), ...)" instead.

WARNING: deprecated syntax "function .^(...)".
Use "function Base.broadcast(::typeof(^), ...)" instead.

WARNING: deprecated syntax "function .^(...)".
Use "function Base.broadcast(::typeof(^), ...)" instead.

WARNING: deprecated syntax "function .==(...)".
Use "function Base.broadcast(::typeof(==), ...)" instead.

WARNING: deprecated syntax "function .==(...)".
Use "function Base.broadcast(::typeof(==), ...)" instead.

WARNING: deprecated syntax "function .==(...)".
Use "function Base.broadcast(::typeof(==), ...)" instead.

WARNING: deprecated syntax "function .==(...)".
Use "function Base.broadcast(::typeof(==), ...)" instead.

WARNING: deprecated syntax "function .==(...)".
Use "function Base.broadcast(::typeof(==), ...)" instead.

WARNING: deprecated syntax "function .!=(...)".
Use "function Base.broadcast(::typeof(!=), ...)" instead.

WARNING: deprecated syntax "function .!=(...)".
Use "function Base.broadcast(::typeof(!=), ...)" instead.

WARNING: deprecated syntax "function .!=(...)".
Use "function Base.broadcast(::typeof(!=), ...)" instead.

WARNING: deprecated syntax "function .!=(...)".
Use "function Base.broadcast(::typeof(!=), ...)" instead.

WARNING: deprecated syntax "function .!=(...)".
Use "function Base.broadcast(::typeof(!=), ...)" instead.

WARNING: deprecated syntax "function .<(...)".
Use "function Base.broadcast(::typeof(<), ...)" instead.

WARNING: deprecated syntax "function .<(...)".
Use "function Base.broadcast(::typeof(<), ...)" instead.

WARNING: deprecated syntax "function .<(...)".
Use "function Base.broadcast(::typeof(<), ...)" instead.

WARNING: deprecated syntax "function .<(...)".
Use "function Base.broadcast(::typeof(<), ...)" instead.

WARNING: deprecated syntax "function .<(...)".
Use "function Base.broadcast(::typeof(<), ...)" instead.

WARNING: deprecated syntax "function .<=(...)".
Use "function Base.broadcast(::typeof(<=), ...)" instead.

WARNING: deprecated syntax "function .<=(...)".
Use "function Base.broadcast(::typeof(<=), ...)" instead.

WARNING: deprecated syntax "function .<=(...)".
Use "function Base.broadcast(::typeof(<=), ...)" instead.

WARNING: deprecated syntax "function .<=(...)".
Use "function Base.broadcast(::typeof(<=), ...)" instead.

WARNING: deprecated syntax "function .<=(...)".
Use "function Base.broadcast(::typeof(<=), ...)" instead.

WARNING: deprecated syntax "function .>(...)".
Use "function Base.broadcast(::typeof(>), ...)" instead.

WARNING: deprecated syntax "function .>(...)".
Use "function Base.broadcast(::typeof(>), ...)" instead.

WARNING: deprecated syntax "function .>(...)".
Use "function Base.broadcast(::typeof(>), ...)" instead.

WARNING: deprecated syntax "function .>(...)".
Use "function Base.broadcast(::typeof(>), ...)" instead.

WARNING: deprecated syntax "function .>(...)".
Use "function Base.broadcast(::typeof(>), ...)" instead.

WARNING: deprecated syntax "function .>=(...)".
Use "function Base.broadcast(::typeof(>=), ...)" instead.

WARNING: deprecated syntax "function .>=(...)".
Use "function Base.broadcast(::typeof(>=), ...)" instead.

WARNING: deprecated syntax "function .>=(...)".
Use "function Base.broadcast(::typeof(>=), ...)" instead.

WARNING: deprecated syntax "function .>=(...)".
Use "function Base.broadcast(::typeof(>=), ...)" instead.

WARNING: deprecated syntax "function .>=(...)".
Use "function Base.broadcast(::typeof(>=), ...)" instead.

WARNING: deprecated syntax "function .+(...)".
Use "function Base.broadcast(::typeof(+), ...)" instead.
WARNING: could not import Base.call into GeometryTypes

WARNING: deprecated syntax "abstract AbstractDistanceField" at /Users/michael/.julia/v0.6/GeometryTypes/src/types.jl:2.
Use "abstract type AbstractDistanceField end" instead.

WARNING: deprecated syntax "abstract AbstractUnsignedDistanceField<:AbstractDistanceField" at /Users/michael/.julia/v0.6/GeometryTypes/src/types.jl:3.
Use "abstract type AbstractUnsignedDistanceField<:AbstractDistanceField end" instead.

WARNING: deprecated syntax "abstract AbstractSignedDistanceField<:AbstractDistanceField" at /Users/michael/.julia/v0.6/GeometryTypes/src/types.jl:4.
Use "abstract type AbstractSignedDistanceField<:AbstractDistanceField end" instead.

WARNING: deprecated syntax "abstract AbstractGeometry{N,T}" at /Users/michael/.julia/v0.6/GeometryTypes/src/types.jl:9.
Use "abstract type AbstractGeometry{N,T} end" instead.

WARNING: deprecated syntax "abstract AbstractMesh{VertT,FaceT}<:AbstractGeometry" at /Users/michael/.julia/v0.6/GeometryTypes/src/types.jl:10.
Use "abstract type AbstractMesh{VertT,FaceT}<:AbstractGeometry end" instead.

WARNING: deprecated syntax "abstract GeometryPrimitive{N,T}<:AbstractGeometry{N,T}" at /Users/michael/.julia/v0.6/GeometryTypes/src/types.jl:11.
Use "abstract type GeometryPrimitive{N,T}<:AbstractGeometry{N,T} end" instead.

WARNING: deprecated syntax "abstract AbstractSimplex{N,T}<:FixedVector{N,T}" at /Users/michael/.julia/v0.6/GeometryTypes/src/types.jl:18.
Use "abstract type AbstractSimplex{N,T}<:FixedVector{N,T} end" instead.

WARNING: deprecated syntax "abstract AbstractFlexibleGeometry{T}" at /Users/michael/.julia/v0.6/GeometryTypes/src/types.jl:161.
Use "abstract type AbstractFlexibleGeometry{T} end" instead.

WARNING: deprecated syntax "typealias AFG AbstractFlexibleGeometry" at /Users/michael/.julia/v0.6/GeometryTypes/src/types.jl:162.
Use "const AFG = AbstractFlexibleGeometry" instead.

WARNING: deprecated syntax "typealias AbstractConvexHull Union{Simplex,FlexibleConvexHull,FlexibleSimplex,HyperCube,HyperRectangle}" at /Users/michael/.julia/v0.6/GeometryTypes/src/types.jl:189.
Use "const AbstractConvexHull = Union{Simplex,FlexibleConvexHull,FlexibleSimplex,HyperCube,HyperRectangle}" instead.
ERROR: LoadError: LoadError: invalid subtyping in definition of AbstractMesh
Stacktrace:
 [1] include_from_node1(::String) at ./loading.jl:539
 [2] include(::String) at ./sysimg.jl:14
 [3] include_from_node1(::String) at ./loading.jl:539
 [4] include(::String) at ./sysimg.jl:14
 [5] anonymous at ./<missing>:2
while loading /Users/michael/.julia/v0.6/GeometryTypes/src/types.jl, in expression starting on line 9
while loading /Users/michael/.julia/v0.6/GeometryTypes/src/GeometryTypes.jl, in expression starting on line 35
ERROR: Failed to precompile GeometryTypes to /Users/michael/.julia/lib/v0.6/GeometryTypes.ji.
Stacktrace:
 [1] compilecache(::String) at ./loading.jl:673
 [2] require(::Symbol) at ./loading.jl:460

In julia v0.6-rc2 on OSX, using GeometryTypes master (plus the fix from #91), the following code segfaults:

using MeshIO, GeometryTypes
using GeometryTypes: isvoid

VT = vertextype(GLNormalMesh)
FT = facetype(GLNormalMesh)
vs = [VT(0., 0, 0), VT(1., 0, 0), VT(0., 1, 0)]
fs = [FT(1, 2, 3)]

m = HomogenousMesh(vs, fs)
HomogenousMesh(m)

I haven't been able to figure out why.

In f89d867 I generalized the N-Face (N >=3) conversion, but it occurs to me that this can be generalized further. For example it should be possible to get all Face{2} from a Face{3}.

I propose the following syntax via call overloads of NTuple:

f = Face{3,Int,0}(1,2,3)
line_segments = NTuple{Face{2,Int,0}}(f)

This feels like an abuse of notation since the NTuple call does not have a determinate number.

Call with e.g.:

a = Vector{Point{3,Float64}}(HyperRectangle())

I think the same should be applied with the getindex syntax.

For porting code from cgkit (Python) I need a cylinder primitive. My question is, which properties are needed. Length and radius are obvious, but perhaps more? See also:
http://cgkit.sourceforge.net/doc2/ccylindergeom.html

JuliaLang/julia#10380

I might be misunderstanding the intention of decompose, but my guess is that these should work.

julia> s = Simplex{3,Point}(Point(1,0,0), Point(0,1,0), Point(0,0,1))
3-element GeometryTypes.Simplex{3,GeometryTypes.Point}:
 [1, 0, 0]
 [0, 1, 0]
 [0, 0, 1]

julia> decompose(Simplex{2}, s)
(GeometryTypes.Point[[1, 0, 0], [0, 1, 0]], GeometryTypes.Point[[0, 1, 0], [0, 0, 1]], GeometryTypes.Point[[0, 0, 1], [1, 0, 0]])

julia> decompose(Simplex{1}, s)
ERROR: MethodError: GeometryTypes.Simplex{1,GeometryTypes.Point}(::GeometryTypes.Point{3,Int64}) is ambiguous. Candidates:
  (::Type{GeometryTypes.Simplex{1,T}})(x::T) where T in GeometryTypes at /Users/goretkin/playgrounds/vamp/packages/v0.6/GeometryTypes/src/simplices.jl:16
  (::Type{GeometryTypes.Simplex{S,T}})(x) where {S, T} in GeometryTypes at /Users/goretkin/playgrounds/vamp/packages/v0.6/GeometryTypes/src/simplices.jl:10
  (::Type{S})(sv::StaticArrays.StaticArray{Tuple{N},T,1} where T where N) where S<:GeometryTypes.Simplex in GeometryTypes at /Users/goretkin/playgrounds/vamp/packages/v0.6/GeometryTypes/src/simplices.jl:6
Possible fix, define
  (::Type{GeometryTypes.Simplex{1,T<:(StaticArrays.StaticArray{Tuple{N},T,1} where T where N)}})(::T<:(StaticArrays.StaticArray{Tuple{N},T,1} where T where N))
Stacktrace:
 [1] decompose(::Type{GeometryTypes.Simplex{1,T} where T}, ::GeometryTypes.Simplex{3,GeometryTypes.Point}) at /Users/goretkin/playgrounds/vamp/packages/v0.6/GeometryTypes/src/decompose.jl:139

julia> decompose(Point, s)
ERROR: MethodError: no method matching decompose(::Type{GeometryTypes.Point}, ::GeometryTypes.Simplex{3,GeometryTypes.Point})
Closest candidates are:
  decompose(::Type{SV<:(StaticArrays.StaticArray{Tuple{N},T,1} where T where N)}, ::GeometryTypes.AbstractGeometry{N,T}, ::Any...) where {SV<:(StaticArrays.StaticArray{Tuple{N},T,1} where T where N), N, T} at /Users/goretkin/playgrounds/vamp/packages/v0.6/GeometryTypes/src/decompose.jl:8
  decompose(::Type{GeometryTypes.Simplex{3,T1}}, ::GeometryTypes.Simplex{N,T2}) where {N, T1, T2} at /Users/goretkin/playgrounds/vamp/packages/v0.6/GeometryTypes/src/decompose.jl:92
  decompose(::Type{GeometryTypes.Simplex{3,T} where T}, ::GeometryTypes.Simplex{N,T}) where {N, T} at /Users/goretkin/playgrounds/vamp/packages/v0.6/GeometryTypes/src/decompose.jl:106
  ...

Just to make sure we don't break anyone's stuff too bad:

julia> Pkg.dependents("GeometryTypes")
7-element Array{AbstractString,1}:

• "GLAbstraction"
• "Meshing"
• "GLVisualize"
• "GLWindow" JuliaGL/GLWindow.jl#19
• "Packing"
• "MeshIO" JuliaIO/MeshIO.jl#12
• "ThreeJS"

Currently the Simplex type has the number of vertices hard coded into its type. Which is perfect for many performance critical situations. But not for all, in some cases, one wants to have a Simplex and iteratively change the number of vertices. This comes up in quite some optimization problems, gjk being the one that bothers me at the moment.

In such situations, a Simplex type with hard coded number of vertices leads to type instability.
So I was wondering if a Simplex type with mutable number of vertices fits into the scope of this package, or if it is better done elsewhere. Same applies to a "convex hull of finitely many points" type.

Hi, so I've started out defining some of my own types (e.g. in GeoJSON.jl), mainly

• Points (both 2 and 3D)
• MultiPoints (a vector of points)
• LineStrings (a vector of points),
• Polygons (a vector of LinearRings[1]), and
• Multi-* (a vector of *; where * can stand for any of Point/LineString/Polygon)

with the itch to generalize them through GeoInterface.jl to support geometries across Shapefile.jl, LibGEOS.jl, and Geodesy.jl. Among other things, it provides a small set of conversion routines to their Compose.jl counterparts here (while awaiting the verdict on issues like rohitvarkey/Compose3D.jl#2)

They have a fairly consistent set of semantics (spelt out across different specifications [2,3,4,5]) with common operations [6] defined on them, partially implemented through experiments in

• Turf.jl which operates on native Julian objects, and
• LibGEOS.jl which operates on wrappers to opaque C objects.

But going forward, for future interoperability, I'd be happy for that responsibility to rest within JuliaGeometry instead. Might you consider providing types for some of the common geometries for Geospatial applications in this repository?

[1]: LinearRings are LineStrings, with matching first and last coordinates
[2]: John R. Herring, Ed., “OpenGIS Implementation Specification for Geographic information - Simple feature access - Part 1: Common architecture,” Oct. 2006.
[3]: Martin Davis, “JTS Technical Specifications,” Mar. 2003. [PDF]
[4]: The GeoJSON Format Specification [link]
[5]: ESRI Shapefile Technical Description [PDF]
[6]: E. Clementini, P. Di Felice, and P. van Oosterom, “A Small Set of Formal Topological Relationships Suitable for End-User Interaction,” Third International Symposium on Large Spatial Databases (SSD). Lecture Notes in Computer Science no. 692, David Abel and Beng Chin Ooi, Eds., Singapore: Springer Verlag, 1993, pp. 277-295. [PDF]

The naming nitpicking continues. I was sitting in a lecture on tetrahedral packing today and learned a pyramid can actually have an arbitrary polygonal base.
See:
https://en.wikipedia.org/wiki/Pyramid_%28geometry%29

Some convenience functions would be nice to be able to transform
1000000×3 Array{Float64,2} to 1000000-element Array{GeometryTypes.Point{3,Float32},1}

The following code implementation is rather slow, about 100 ms. Is there a faster way?

using GeometryTypes, BenchmarkTools
a = rand(Float32,10^6,3);

function my1(a)
    v = vertextype(GLNormalMesh)[]
    for i=1:size(a,1)
        push!(v,Point{3,Float32}(a[i,1:3]))
    end
    v
end

function my2(a::Array{Float32}  )
    [Point{3,Float32}(a[i,1:3]) for i=1:size(a,1)]
end

These two function are about same speed

@benchmark my2(a)

gives

BenchmarkTools.Trial:
  memory estimate:  144.82 MiB
  allocs estimate:  2999509
  --------------
  minimum time:     95.433 ms (17.50% GC)
  median time:      105.822 ms (19.48% GC)
  mean time:        126.110 ms (31.98% GC)
  maximum time:     222.663 ms (60.60% GC)
  --------------
  samples:          40
  evals/sample:     1

Since FixedSizeArrays will get replaced by StaticArrays are there plans to port GeometryTypes.jl to StaticArrays?

Hello,
The README.md says "Some of the types offered by GeometryTypes visualized with GLVisualize"

Would it be possible to see the exact commands (or at least an example) of how the images were rendered?

Thanks!

In prior versions of GeometryTypes, Vec(0.0, 0, 0) would create a Vec{3, Float64}, but on master it instead creates a Vec{1,Tuple{Float64,Int64,Int64}}

I'll see if I can fix this.

Hi,

Routine width() stopped working. I found out that its now widths, but havent seen anything documenting the change - am I missing it somewhere?

Thx

I think the rest of the vertices methods return Array{T,1}.

MeshIO test fails when master of GeometryTypes is used. The failure can be seen in https://travis-ci.org/JuliaIO/MeshIO.jl/jobs/99826624. The pull that found this was JuliaIO/MeshIO.jl#4. I can confirm the PR succeed locally when using GeometryTypes=0.1.0 while it fails when master of GeometryTypes is used.

Edit:
Tests on master of MeshIO and GeometryTypes do also fail

In investigating a deprecation warning in another package (GLVisualize.jl) I realized the deprecation was actually in GeometryTypes.jl. To see the original issue and its traceback to GeometryTypes.jl, please see here.

The deprecated syntax arises because map! now expects a call of the format map!(function, destination, collection...) instead of (if I'm understanding correctly) map!(function, collection...)

I try to make a GLFace and I get the following error.

ERROR: InexactError()
Stacktrace:
 [1] Type at C:\Users\mohd\.julia\v0.6\GeometryTypes\src\types.jl:78 [inlined]
 [2] convert at C:\Users\mohd\.julia\v0.6\GeometryTypes\src\faces.jl:11 [inlined
]
 [3] convert at C:\Users\mohd\.julia\v0.6\GeometryTypes\src\faces.jl:15 [inlined
]
 [4] macro expansion at C:\Users\mohd\.julia\v0.6\StaticArrays\src\util.jl:11 [i
nlined]
 [5] convert_ntuple at C:\Users\mohd\.julia\v0.6\StaticArrays\src\util.jl:8 [inl
ined]
 [6] Type at C:\Users\mohd\.julia\v0.6\StaticArrays\src\FixedSizeArrays.jl:98 [i
nlined]
 [7] Type at C:\Users\mohd\.julia\v0.6\StaticArrays\src\convert.jl:3 [inlined]
 [8] decompose_to_glmesh_3d(::VTKDataTypes.VTKStructuredData{Float64}) at C:\Use
rs\mohd\.julia\v0.6\VTKDataTypes\src\GLMesh.jl:197
 [9] #GLMesh#129(::String, ::Int64, ::Float64, ::Function, ::VTKDataTypes.VTKRec
tilinearData{Float64}) at C:\Users\mohd\.julia\v0.6\VTKDataTypes\src\GLMesh.jl:1
34
 [10] GLMesh(::VTKDataTypes.VTKRectilinearData{Float64}) at C:\Users\mohd\.julia
\v0.6\VTKDataTypes\src\GLMesh.jl:127

I suppose it is similar to the last fix committed. Also the README still says Face{3,UInt32,-1} is the way to make a GL face, but it seems you changed it to Face{3,Int} and GLFace{3} for offsets 0 and -1 respectively, am I right?

julia> undefined_names(mod) = filter(s->!isdefined(mod, s), names(mod, false, true))
undefined_names (generic function with 1 method)

julia> undefined_names(GeometryTypes)
2-element Array{Symbol,1}:
 :isoutside  
 :triangulate

(I see that triangulate was deprecated once, but I didn't ever see isoutside defined)

I just wanted to let you know that I've been working on an implementation of EnhancedGJK (Cameron's improved version of GJK which uses pre-computed neighbors of mesh vertices to improve performance for repeated calls on the same pair of geometries with slightly different poses): https://github.com/rdeits/EnhancedGJK.jl

I'm using GeometryTypes under the hood, but have had to encapsulate the functions from GeometryTypes rather than extending them because I need slightly different behavior (and because I'm using StaticArrays internally).

However, as a part of that project, I've implemented Johnson's distance subalgorithm, the procedure for computing the vertex weights for the GJK simplex (equivalent to what GeometryTypes.proj_sqdist does. I've found that Johnson's algorithm is much faster (less than 100 nanoseconds for a 3-dimensional simplex, compared to several hundred nanoseconds for the implementation in GeometryTypes which uses the pseudoinverse). It also has the benefit of producing a valid (but non-unique) solution when the simplex is not linearly independent, whereas the pseudoinverse method returns NaNs. I think it might be possible to port the algorithm into GeometryTypes to replace the current proj_sqdist implementation. Would you be interested in that?

Would people find this useful? We could just bring it under a submodule for now:

https://github.com/JuliaGeometry/HyperRectangles.jl

I was going to publish it to METADATA, but I think coordinating efforts would be best at this point.

cc: @KristofferC @SimonDanisch @rohitvarkey

Should there be an explicit Polygon type? Right now the code uses AbstractArray{Point} and Vector{Point} (in only one place each) to describe a Polygon.