Even with this very early brute force technique I get maximum framerate on my 2 year old machine.
I simply used point sprites - and the hardware culling speeds things up, as I have seen during the test.
Only thing that I struggled with, and could not fix yet: the points appear as semi transparent. I would have liked them to be totally opaque.
Also, they are currently squares, not circles. This is by design and could be fixed easily. There are two options for a fix: Write a simple shader with (u*u + v*v) > 1.0 = transparent, or simply use the particle material with a texture, that shows a circle. As I just said - both very simple ways to turn squares into circles...
8)
what do you mean by "particle material", please? jmonkey doesn't make any equivalent to gl_PointCoords available to shaders
@hcavra said:
what do you mean by "particle material", please? jmonkey doesn't make any equivalent to gl_PointCoords available to shaders
I'm not sure where you get this information, actually. You do know the source code is available and google code easily allows you to search it?
Notice this from the particle material:
http://code.google.com/p/jmonkeyengine/source/browse/trunk/engine/src/core-data/Common/MatDefs/Misc/Particle.frag
Notice the use of: gl_PointCoord
It's only another quick step to find the JME tests that use this material... I provided that in the other thread, though. It was taking apart that example and related classes which let me do my own point sprite related shaders... of which I have at least 4 or so.
@metaquanta said:
Hello @Ogli,
I'm using your cloud generator here: https://github.com/metaquanta/jove
thanks a lot!
Visualization is a nice and useful application of render engines like jME.
Both science and economy can make use of such visualization tools.
I wish you merry coding times and success!
Iāve been looking for weeks for a way to do point cloud segmentation in Java, so desperate I already started to learn c++ just in order to use the PCL. This saved me months!!
Do you know how I can convert pc. files to the float array? Iām trying to parse .ply files but I find this difficultā¦
Iām sorry, but I did not do any work on point clouds, but I had a lot of ideas for this back then.
Seems like this is what you needed for your object recognition - some 3d points with color.
You would typically have a vast amount of points - the recently scanned jesus of rio consists of over 100.000.000 points.
To render this efficiently, you would implement an LOD algorithm (Level Of Detail), that does not visualize every of those points, but only the most important ones.
Typically I would use color to indicate density (red means many points, green means few points), but since you probably need color ā¦ for ā¦ well ā¦ your photo color this is not possible - so just fuse some points in a binary tree or something like that and also segment your point cloud into cubes (octree or grit based approach). In other words: your point cloud does consist of several boxes that hold only parts of the whole cloud, so that the in-game-virtual-camera can clip those out that are currently not seen & then also have these boxes in several versions with: full points (e.g. 10742 points are in a particular box), 50% version (only show 5371), 50% of 50% version (only show 2685), 50% of 50% of 50% version (1342), etc.
About those two file formats: I did not look for the file format. First determine if you can find some info on that (e.g. is it binary or txt, what data is stored, how is it stored), then read in the file according to the format (Java can read binary and text files, your Loader will fill an internal data structure that represents the boxes and their LOD versions).
It might also help to look for a Loader for that format on the internet.
But what you really need is a solid understanding of the file format (if I were to design such a format, then I would incorporate the idea of āboxesā and āLODā, but also provide a brute force (raw) format with simply all points in a very long list, maybe with file header (magic number, version number, maximum and minimum 3d coordinates, number of points stored, and such stuff).
The file-reading is working now. What Iām currently doing is to basically strip all the additional information from the file (.txt) manually, so that Iām left with just the points (like the raw format you mentioned). Fortunately the formats are well documented so Iām confident Iāll get it working without cheating soon.
Well, thatās pretty cool. Wish you luck and success.
I was experimenting with my kinect 2, with a cheap photogrammetry programm and with the free 123D catch cloud. Unfortunately, the more sophisticated tools like agisoft photoscan cost alot of money.
Another hint for the ābox segmentationā:
It would be good to fuse boxes hierarchically, since it doesnāt make much sense to render boxes with less than a few hundred or a few thousand points (2^16 is a full buffer in jME3, which means 65k points). You always try to make large batches. An octree is such a fuse-up (or split-down) structure - e.g. 8 max resolution boxes with ca. 10k points each fuse into one parent-box with 10k points, then 8 parent-boxes fuse into one parent-parent-box, etc.
Also make some tests on your machine with raw rendering first - some millions of points are possible with current hardware. For smaller objects this might be sufficient. For example: a human body typically has 1,73 mĀ² area (4.4 by 4.4 feet) - which means that with 1,730,000 points you have one point for every square-millimeter (1/25 by 1/25 inches).
Of course this is after the human has been separated from the background (the living room or photo studio).
by the way - the smileys of the new forum suck!
a āsmileā is translated to a āstupid laughing with closed eyesā.
I wish we had the good old monkey smileys back - or at least some reasonable standard smileysā¦
(2^16 is a full buffer in jME3, which means 65k points).
Oh, I made a little mistake here - this limit of 65k points is only for indexed triangle meshes. So, you might directly render a million points or so. Index buffers are only needed when you use triangles instead of points.
:chimpanzee_closedgrin:
Is there a complete list of codes for the old smileys?
I only have the codes for the old ones in a txt file.
well, I was using the default sphere object when I discovered this.
didnāt know that int buffers are possible too, thanks for that hint pspeed.
also I wonder if index buffers are needed when using triangle strips - I guess no.
will check this when my bitmap text library and project pdf are finished.
Itās a trade off. If you just have positions then the trade off is easier to calculate. If you also have things like shared normals, shared texture coordinates, etc. then even triangle strips benefit from index buffers.
Edit: at least for the most common use-cases for triangle strips.
this is not possible - so just fuse some points in a binary tree or something like that and also segment your point cloud into cubes (octree or grit based approach). In other words: your point cloud does consist of several boxes that hold only parts of the whole cloud, so that the in-game-virtual-camera can clip those out that are currently not seen & then also have these boxes in several versions with: full points (e.g. 10742 points are in a particular box), 50% version (only show 5371), 50% of 50% version (only show 2685), 50% of 50% of 50% version (1342), etc.