It has been two days as GSoC’s the coding time started. So I’m going to present what have I done this past two days…
I am currently making the API for the jNavigation. If you look at com.jme3.ai.recast, you can see what the class will be in API for jNavigation.
Name of methods in them, and the objects sent to those methods are not appropriate for good API, yet. This will be corrected until Sunday. I will post update on that matter in this thread.
In this first devlog, I will be speaking how the navigation meshes are built in Recast navigation.
Prepare the input triangle mesh. - this will be loaded from jME3 Mesh class, and I will build appropriate converter to Recast needs.
Build a Heightfield.
Build a CompactHeightfield.
Build a ContourSet.
Build a PolyMesh
Build a PolyMeshDetail.
Use the PolyMesh and PolyMeshDetail to build a Detour navigation mesh tile.
You can find more about processes in this link. You can find here more about how Recast works.
My question about API for community would be:
Is it better to build separate class builder for these stages, or one NavMeshBuilder that will build Navigation mesh from Mesh to Navigation mesh, or maybe something third.
The reason for this question is because I thought at first to make JNI, then make game and after that to smooth the API, but JNI is not very flexible, and because of that I would like to make the API, that will not change drastically later.
“Provides an interface for optional logging and performance tracking of the Recast build process. This class does not provide logging or timer functionality on its own. Both must be provided by a concrete implementation by overriding the protected member functions. Also, this class does not provide an interface for extracting log messages. (Only adding them.) So concrete implementations must provide one. If no logging or timers are required, just pass an instance of this class through the Recast build process.”
All of its methods are virtual (Java: abstract = C++: virtual) so there is no implementation. My thinking is that the average programmer in jME won’t need this functionality to track performance of Recast build. If logger is needed, I think is better to use Logger that can be found implemented in Java.
What do you think?
P.S. If nobody answers, I will understand that everybody agrees with me that Context shouldn’t go to the API. =D
Thanks for the post Tihomir!
For the builders, they might end up having separate method signatures so a single API class (interface) of something like buildNavMesh(Spatial someKindOfSpatial) might not work. But having all these methods in a single class could be large and not very modular. I suggest break out a Factory pattern: abstracting the creation of the meshes into several separate builder classes that is called from several factory classes. For example: PolyMeshNavMeshFactory, HeightfieldNavMeshFactory etc.
As for the logging when I added some navmesh building for the java-version of recast a few years ago it was beneficial to track the progress of the build to know how far along it was. Having logs pop up could be a good way to show that it didn’t just crash and hang up. It could take several minutes to build a navmesh for a large map and the user will need some feedback for that.
I was looking at the Recast Navigation code and at first I saw the input for all kind of methods was the class Context. As I learned about it I thought it was very useful, but now I see that the class is only set there for now, as means for future expansion. It is called everywhere, has only interface, and it is not used anywhere. In every function that uses Context as parameter it is ignored.
[c]
void rcIgnoreUnused ( const T & )
Used to ignore a function parameter.
VS complains about unused parameters and this silences the warning.
Parameters
[in] _ Unused parameter
[/c]
They call this function for the Context parameter. The Recast Navigation doesn’t have logging feature. I can make API for that feature, but it won’t work if Recast community never finishes it.
As for API, thanks, I will think something with that kind of pattern that is easy to use.
Send an email to the Recast dev mailing list, forums, or poke them on irc if they have a room, and ask them what their plans for that Context class are. If it is going to be used, in what version, and when that version will be released. They should be able to give you a heads up on what to expect with future versions.
So the Context parameter just seems to be getting in the way right now? If it isn’t used in their code, it can be left unimplemented for now.
If I saw everything correctly Context is the class meant for the logging option, but is not implemented completely yet. Is that feature going to be completed in next versions, or will that be up to user to implement if he want to use it? If it is going to be completed in next version, what will it contain and when is it expected to be released?
Mikko:
You are supposed to derive from the class and make the actualy implementation yourself, see:https://github.com/memononen/recastnavigation/blob/master/RecastDemo/Include/SampleInterfaces.h
–mikko
That feature can be easily added later with java.util.logging.logger (or durring GSoC, if I fail to do get working building NavMesh from the start :-[ )
The basic structure for recast module is finished. There will be two packages:
com.jme3.ai.recast.builders It contains Builder interface that is same for all builders inside of recast module and builders for every single step of recast process. Every builder will contain reference to the object that it can change and methods how to do it. Inside structure of these class will change as it only temporary for me to see what data I will need, but native methods will enable to see what can be done with structures
com.jme3.ai.recast.structures It contains structures that is used by recast process (All of them extends BoundedField). Some of them have structures that enables to see data inside those structures used by recast (nested classes). Those will probably be enabled later on as it is not provided by Recast and it only said how to be used to iterate between them (Mikko said that end user will be grateful to have those data). Inside structure of these class will change as it only temporary for me to see what data I will need.
If you look at project you will also see com.jme3.ai.recast.structures.sub . There is two structures for which I couldn’t find appropriate documentation to see for what is used or how to use it if it is structure for letting user to see data about CompactHeightfield. I send message to recast group and I am waiting for an answer. If it is of use to end user it will be putted inside of CompactHeightfield, and if not then it will be deleted.
If everybody agrees with structure, tomorrow will begin work on Java Native Interface.
Interesting side note: The DayZ developers also started to use the recast / navmesh technique in their game now. http://dayzdev.tumblr.com (Just now? Noobs ;))
Noticed you haven’t posted a devlog update in 10 days. Any updates?
PS: Good luck with the JNI. It will be hard. Tried doing it myself, was way too complex (bare in mind that there’s nothing I hate more than JNI).
Have you considered using JNA? It’s a lot easier imo (no C/C++ at all required)
@normen said:
Doing proper JNI creates much more portable code, if you can code C/C++ JNI isn't hard at all.
Between C’s complete lack of object orientation and C++'s lack of default memory management (as with all native code) I figured it’d be best that somebody who forgets to drink doesn’t learn either, so yeh that was the problem.
@fabsterpal said:
Noticed you haven't posted a devlog update in 10 days. Any updates?
There aren't anything special to be said. It had started the hard and boring work. I have to watch what user can change and what params are only for watching. Also I can't test anything until I finish the rest of module.
