Administrator
|
Hello
There was a thread on javagaming.org about my game since February 2007, my first person shooter was created in October 2006 and opensourced in November 2006, but as JavaGaming switched to read-only mode in January 2023, I'll post some updates on this forum. T.U.E.R website contains some documentation and a playable version of the game. I've been working on several algorithms of mesh decimation, one of them since about ten years. I'm almost ready to release a fully working version of coplanar adjacent triangles merge, I reduced the memory footprint required to simply a ceiling composed of about 123000 triangles, it required at least 60 GB, it should require something a lot more reasonable, i.e around 1 MB. I implemented a very naive 2D sparse array to solve this problem. I used a smaller ceiling (222 triangles) in the meantime. A very few invalid triangles are produced, I'll have to fix this bug as soon as possible. I obtained 14 triangles but I expect to obtain between 15 and 20 triangles when the bug is fixed. On the long term, I'll have to use more efficient abstract data types, probably a forest of graphs. JFPSM, the editor of the game, uses Swing. I still hesitate to re-evaluate the use of NetBeans Platform in order to improve the tiny image editor and benefit of much more build-in features, undo/redo management, project management, etc. There are several projects using JOGL that use NetBeans Platform too, for example Praxis Live and Gephi, they could be excellent sources of inspiration for me. Best regards.
Julien Gouesse | Personal blog | Website
|
Administrator
|
Hello
I fully fixed the optimizer Tuesday and I sent my contribution to Graphstore API main maintainer tonight so that I can use this API to build graphs without depending on Joda-Time. The next step consists in modifying my algorithms to support much larger meshes. Making my stuff work after ten years is a huge relief :) Best regards.
Julien Gouesse | Personal blog | Website
|
Administrator
|
In reply to this post by gouessej
Hello
I've just written an article about the progress in my game: https://gouessej.wordpress.com/2023/04/06/truly-unusual-experience-of-revolution-17-ans-deja-truly-unusual-experience-of-revolution-already-17-years/ I had written no article about my game during about 7 years, I had many things to explain. Enjoy.
Julien Gouesse | Personal blog | Website
|
Administrator
|
Noice, thanks .. will soothe my morning after a hacking round.
Yeah, I noticed that the good people of France are somewhat active as of late. I would wish more people would peacefully express their stance for peace these days and not for the MIC agenda and so forth, causing all the suffering as it was the plan all along :-( Sorry, couldn't help it. Happy Easter. |
Administrator
|
In reply to this post by gouessej
Interesting, especially the mesh (rectangle/triangle) reduction. Guess I will have a look at it.
I also need to fix Graph's tessellation, as the current Delauny method doesn't work for all corner cases (I have once listed 'odd glyphs' of certain fonts). Oh well .. so many things ;-) Cheers and again, happy Easter! |
Administrator
|
I'm currently improving the TestNG unit tests to determine which cases produce the expected results and which don't. Some StackOverflow users downvoted my few answers about my implementation, there are probably more efficient solutions but they aren't documented enough. I'll have to document all this a lot better. I think that I'm not very far from a reliable solution. If you ever need to do something similar, you'll need something that scales better but a working implementation is better than nothing.
I studied Delaunay's triangulation during my Master degree. Maybe there's a working implementation in ardor3d-terrain, I don't remember exactly how Renanse and MrCoder implemented the terrain generation. There are at least two kinds of algorithms to perform Delaunay's triangulation, Destruction-Construction (higher complexity) and Flip Algorithm. I noticed a very few characters not correctly displayed in your videos. Are you sure that your implementation is correct or is Delaunay's triangulation not suitable to solve your problem?
Julien Gouesse | Personal blog | Website
|
Administrator
|
I showed images where it fails and it seems that Delauny is not suitable w/o constraints like 'don't leave the shape', when finding the edges.
|
Administrator
|
Does CDTriangulator2DExpAddOn.processLineAAImpl() try to check whether 2 triangles compose a rectangle? If it's the case and if the bug is in this part, it won't be hard to fix. The triangles must be in the same plane (use the plane equation composed of a normalized normal and a constant), they must have distinct right angles (use a dot product) and share the same hypotenuse (compare the vertices not on the right angles). As you talk about Delaunay, the limitation or bug is rather in CDTriangulator2D, isn't it?
Julien Gouesse | Personal blog | Website
|
Administrator
|
CDTriangulator2D as in Delauny is using its in/out tri surrounding trick (AFAIK) to determine the order of the vertices/edges -> triangles from mesh.
Now that is all fine, but for example the 'M' two y-max points are wrongly interpreted with one font, I isolated a this glyph (like others I fixed) .. `Glyph03FreeMonoRegular_M` in the demos sub-module. I started digging deeper in Delauny, so some use constraints, i.e. testing some criteria to weight options. Our does this for sure for the curve-points, as they must be preserved (quadratic bezier). The straight lines though seem to not have an additional check. Back then Rami suggested to test with a different Tessellation .. maybe. Problem, the classic well working algo is also rotten slow :)) |
Administrator
|
I understand your situation, it often happens to me. Sometimes, the papers I read aren't detailed enough to obtain a working implementation and I have to start from scratch. I thought that it wasn't critical as I was working on calculations that wouldn't have to be performed when responsiveness is crucial but when the datasets are big, either the memory consumption becomes insane (more than 60 GB in my optimizer without using a sparse array) or it takes so long (more than a day?) that it can't be easily tested.
I've just repaired the computation of largest rectangles. By the way, very well documented source code is easier to maintain on the long term. I just look for the largest full areas in descending order and it works. It's very naive but it's fast enough for now. As I separate the considerations and as I have some strong unit tests, I could replace this implementation by a better one later without having to modify large parts of the source code.
Julien Gouesse | Personal blog | Website
|
Administrator
|
In reply to this post by gouessej
Hello
I've just switched from Groovy to Kotlin in the Gradle build scripts, it seems to work with Gradle 8.10. Best regards.
Julien Gouesse | Personal blog | Website
|
Free forum by Nabble | Edit this page |