gama.old
gama.old copied to clipboard
Any_point_in and Any_location_in IN a 3D geometry do not take the z value
Steps to reproduce
I have a 3D object (geoemtry) 2. I create randomly agents with location is set with these two operators. 3. Agents are created but they are flat, not situated in good 3D position
Expected behavior
Tell us what should happen (include all relevant expectations) Create agents inside a 3D bound
Actual behavior
Tell us what happens instead (include relevant information, like logs, snapshots, etc.)

System and version
Which version of GAMA, JDK, OS ... (if necessary, copy Help>Installation Details>Configuration in GAMA) Gama git
Very nice image! So as expected the agent are created in the 2D envelope of the complex 3D shape. So yes of course it would be great to have agent created in the 3D shape and being able to evolve in this bone shape but indeed the actual structure of GAMA represents a 3D geometry loaded form an .obj file in a 2D world.
How do you load your agent do you use something like this?
geometry shape <- obj_file("../includes/teapot.obj") as geometry;
I don't remember exactly how is handle the 3D bounds for .obj file but we should be able to extract at least the bounding box by computing the min Z and max Z.
So I don't think it's a an OpenGL issue but a more global GAMA one related to representing any geometry in a 3D world.
Yes, it's globally relate to representing any geometry in a 3D world, but i cannot find suggestions how to implement it or workaorund or development direction . I remember sometime we have discussion about adding z to gamapoint or sthg like that? Do you remember what should we do for a totally 3D GAMA?
Hi,
Right now, all the geometries (incl. points) are represented in 3D (i.e. they all have a z ordinate and all geometries have a 3D envelope attached to them).
The problem is that:
- all geometrical operations depend on JTS, which only operates in a 2D world (and there is no real plan to move it to 3D anytime soon)
- the status of 2D geometries in a 3D world (i.e. geometries with a zero depth or height) is complex. There needs to be separate operations for them (as they have a « depth » of zero, so for instance a regular « contains » would not work).
- the 2D.5 geometries (like the one produced by « cube ») only represent a depth in addition to the 2D geometry, so as to remain compatible with JTS, while the geometries loaded from 3D files (3DS, etc.) represent all their points in 3D — they are not compatible with JTS, as they were only used, at the beginning, for display operations.
Having a 3D GAMA would require a complete rewrite of the geometrical operators, with some operations not yet implemented in any library (i.e. intersection of arbitrary 3D shapes, for instance).
This can be a goal, but not one we can reach anytime soon…
Alexis
—
Representative of IRD in Vietnam and Philippines http://en.vietnam.ird.fr http://en.vietnam.ird.fr/
Senior Researcher, co-director, UMI UMMISCO 209, IRD & UPMC, France. http://ummisco.fr http://ummisco.fr/
Director, ICTLab, USTH, Hanoi, Vietnam http://ictlab.usth.edu.vn http://ictlab.usth.edu.vn/
[email protected] | http://goo.gl/4ewFdJ http://goo.gl/4ewFdJ [Vietnam] +84915088155 [France] +33608698845 GAMA: http://gama-platform.org http://gama-platform.org/
Le 29 juin 2017 à 07:59, HUYNH Quang-Nghi [email protected] a écrit :
Yes, it's globally relate to representing any geometry in a 3D world, but i cannot find suggestions how to implement it or workaorund or development direction . I remember sometime we have discussion about adding z to gamapoint or sthg like that? Do you remember what should we do for a totally 3D GAMA?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gama-platform/gama/issues/2199#issuecomment-311832737, or mute the thread https://github.com/notifications/unsubscribe-auth/AAjWuDaEVMhhfKDm85G5K5oTXOBoXkWNks5sIvb3gaJpZM4OFIGv.
Subsumed by #2206
Reopening this issue for the next round of development on GAMA 2.0