make a cloud of dots

Hi,

I search to paint a cloud of dots.
with the word MESH in GEOMETRY you can design : line, polygone, polylist, triangle …
I don’t see anything in the documentation COLLADA 1.4.1 specification june 2006.
Is it possible to design a cloud of dots ???

I use collview to see the result.

Thanks

Collada doesn’t have a points primitive, but it has a <lines> element. A line is specified with two endpoints, but if you make the endpoints the same then you’ll get what you want.

Steve

Hi,

according to the following quotations point primitives seem to be defined !?

  • Collada book p. 52/53:

A mesh may not have any child elements, except for a cloud of points without lines or polygons.

The <vertices> and <source> elements are the only required child elements of the <mesh> element, because that is all that is needed to represent a cloud of points.

  • Collada spec 1.4.1 2nd, p. 5-134:

Here is an example of a <vertices> element that describes the vertices of a mesh:
<mesh>
<source id=“position”/>
<vertices id=“verts”>
<input semantic=“POSITION” source="#position"/>
</vertices>
</mesh>

August

The primitives in Collada are triangles, trifans, tristrips, polygons, polylist, lines, and linestrips. There is no points primitive unfortunately.

The book may be misleading, it meant to say Point Cloud as in:

http://en.wikipedia.org/wiki/Point_cloud

which COLLADA provides.

What would you like to do exactly?
What point primitive are you looking for?

Hi,

We want to design a sky of stars.
Each star is a point.
We will use opengl with the parameter GL_POINT and the function glPointSize.

Which is the best way to to this ??

Can we see all these points with standard COLLADA viewer ???

Thanks

Use a <lines> element where each pair of points is the same. That’ll give you the equivalent of GL_POINTS.

It depends on the viewer and whether or not it supports the (somewhat rarely used) <lines> element. You’ll have to test and see.

Are there any plans to support points ?

this seems a strange omission to me ( but I know nothing :oops: )

I’m working with LIDAR files and can have millions and into hundreds of millions, having to make a 3d representation of a point rather than using something like GL_POINT will be just well eekkkk

We have a requirements to be able to show the point cloud as points in apps Goggle Earth etc…

will be just well eekkkk

And so is encoding to ASCII XML :wink:

We have a requirements to be able to show the point cloud as points in apps Goggle Earth etc…

I think you’ll be VERY disappointed in performance of GE in this case, and how much data it can really handle. I’ve been using COLLADA for years for the sole purpose of generating data for GE, and have wished for a better alternative (not COLLADA’s fault, just not best choice for GE runtime data IMO).

Do you REALLY need to see a LIDAR point cloud in GE though? A point cloud isn’t really a surface, just samples taken FROM a surface. Why not do a really low poly representative surface with a texture map consisting of point plots for instance?

If the app you’re targeting supports Collada’s <lines> primitive then you can use that to simulate points. If the app you’re targeting doesn’t support <lines> then it’s unlikely they’d support a <points> primitive if we added one to the spec.

But I agree that a <points> primitive would be nice.

The main feature that a <points> primitive would provide is the “material” attribute that would enable an <effect> to be bound to all (or difference portions) of the point cloud.

Is there anything else that proponents of points want?

When rendering points you often want to set the point size (also mentioned by ZINS above). If we were to add a points primitive having a first class point size setting would be useful (and analogously a line width setting for <lines>). Relegating these settings to the FX system would hurt interoperability of these parameters because everybody would just end up making their own <extra>s.

The <geometry> element in COLLADA does not include any rendering (or other domain processing specific) attributes. In this case for visualization, those belong entirely in the material.

For abstract interoperability, distinct from the API profiles (e.g. <profile_CG>), proposals for things like point size, line width, double sided, etc. rendering attributes should focus on enhancements to <profile_COMMON>.

The latest version of the Feeling Engine supports the display and measurement of geo-referenced point clouds from LIDAR data, along with the rest of COLLADA goodness (e.g. geo-referenced buildings and animated cars and pedestrians).

This was pretty simple for us to implement, since our engine already fully supported dynamic external referencing, so the point clouds are imported directly from the format native to the LIDAR scanner (PTX in this case). We implemented an automatic point cloud optimization routine to handle millions of points at interactive rate. The result is a Google Earth-like experience, with useful features:

  • You have complete control on which building(s), terrain and point clouds are displayed, through a layer UI. We support multiple LODs (Level of details) for each of these elements.
  • We added measurement capability, e.g. what is the distance or height difference between this point in the point cloud, and the corner or the center of this building.

We support a ton of other features that are desirable for GIS applications, e.g. integration into all major browsers, support for the Space Navigator, etc.

Contact me directly if you’re interested in licensing this tech.