What does “not colored correctly” mean?
And which test did you run exactly?
TestPointSprite.java i think the file name was. Did some OpenGL calls directly and set up a point mesh. It was supposed to give a smoke effect.
The sprites are colored uniformly. The reason seems to be both components of gl_PointCoord are 0 everywhere. If I do like a tex-coord draw but with pointcoord I get only black…
There are other people with intel cards having that problem i saw on google. Probably not worth spending any more time on.
PointSprite should look like this:
at least if you change those two
emit.setStartColor(ColorRGBA.Red);
emit.setEndColor(ColorRGBA.Blue);
This is on a 4 years old radeon 3800HD, so pretty one of the lowest level cards you will find out there.
updated the tread with a video of the page loading
WELL DONE!! This addon will be very useful!!! I hope you will make it as NBM for JMPlatform. 
Or possibly, the core devs would like to put it into the JME core.
@mifth
I’m very glad you like it so far. I am still focusing heavily on the paging component so it will take some more time before i start integrating the trees and grass.
Sure I can make a module out of it, but maybe make one stand alone module out of the paging engine, and another for the vegetation stuff? Or at least separate them somehow. not sure how to do that yet.
Loading & caching isn’t something the user has to worry about much btw., or indeed how to use it at all. The only things you specify to the paging engine is the pagesize and the far viewing range (or one range for each LOD if you use many), and the engine takes care of the rest. Most of the other stuff you put in the pageloader. You can go in and change a few constants used in caching, but its often just as good to try different pagesizes instead.
Also I’m not so sure about the “page” naming convention. Is “paging engine” the best name? Is “geometry pages” the best name for the nodes etc. Open for suggestions here.
That’s how i stay efficient btw. by avoiding having to do any original thinking of my own. 
It’s next to impossible to use standard LODs with trees - particularly if its low to medium poly models. I added support for lod levels (through Spatial.setLodLevel() or GeometryBatchFactory’s lod stuff), but I’m thinking about removing it altogether. Continuous lod would look even worse probably (i tried using 7 lod levels at one time).
There is an additional system in place that uses multiple nodes for each page - LOD0 models on one, LOD1 on the next etc. The nodes can be switched at a certain distance (which of course looks like the usual dLOD system), or blended together with alpha. That system will remain in place, because it’s needed for switching between representations that are very different, such as model-to-impostors. It’s the best choice i think for geometry LOD.
Got lots of shader work to look forward to…
For trees, its better to use imposters (2D billboards) then to use LOD because the 2D alpha blended branches on the trees work very badly with the indexed LOD jME3 is using.
This article explains how to do it well:
http://blog.wolfire.com/2010/10/Imposters
Please if you can seperate the vegetation code from the paging, makes it easier to inegrate it in eventually existing third party paging concepts. In my case I am in need of vegatation only. I guess people without any continuous/paging requirements would have it easier to just not use it, instead of integrating code they won’t need…
Hmm… that’s some good stuff. Thanks. I just started converting the impostor code, maybe its enough with just 1 geometry LOD + impostors, never even thought of that. Gonna do that first and see how it looks, and also add stuff from that article. A lot of it is already in the PG code.
@ghoust
I wount do that sorry. I need the paging stuff and I need vegetation finished as soon as possible so i can use it in my own apps. Separating it entirely from the paging engine would be too much work.
Progressing nicely now. Grass is implemented, but I don’t think I’ll video it until the tree shaders are made and I have something a little nicer to show.
Hmm, seems you can mask the bits in the random generated numbers pretty aggressively and still retain statistical accuracy. Which is great when generating integers (like get an integer between 0 and n).
Have to try some stuff but I’ll be back with some more info later.
1 Like
The core paging engine is basically ready for testing now. Just need some cleanup.
I separated it from everything else but added a simple system for loading terrainquads instead. It’s very primitive at this point, you just specify max visible range and the terrainsize you’re gonna use, then add a bunch of terrains with (x,z) indices so the engine knows where to put them (in relation to one another).
The point of adding the terrain stuff now is mostly just to show how an implementation can be made. In mine, you don’t even have to reference PagedGeometry, or even know it’s there. Everything is taken care of. All you do is something like this:
[java]
group = new TerrainGroup(512, 600f , assetManager,rootNode,camera);
for (int i = -1; i <= 1; i++)
for(int j = -1; j <= 1; j++)
group.addTerrain(_generateTerrain(), i, j);
group.buildTerrainGroup();
[/java]
Then run “group.update(tpf)” every frame. It’ll start crapping out terrainquads like there’s no tomorrow.
Ok I chose to use a binary file loading system instead of terrains as the default implementation. This makes the most sense i suppose.
This is what will be included in the first release, and will probably be the model for all following releases to come:
- The paging engine.
- An implementation for (binary) object placement based on xz-indices. This could be used for entire scenes, or just the terrains stored in binary files, for example.
The objects will occupy an entire page each, and will be loaded/unloaded based on viewing distance.
- An implementation for object placement based on coordinates and page-size. Objects are added and then sorted into appropriate pages based on their coordinates, then loaded-unloaded as groups.
This could be used to load anything that is inappropriate for the treeloader, and needs to be added as binaries (high poly models for example, with their own custom LOD controls).
The engine is done and ready to go. Once I have finished the binary stuff I’ll put it in a proper “distribution package”.
I’ll keep making improvements to it, but focus mainly on the treeloader. Once that is done I will work on the grass loader. I will release it without a default impostoring system at first, because it will become a bit more sophisticated then intended, so it will take more time.
Video coming up.
uh i deleted the terrain stuff when making a module. I don’t need it really, but i wanted the indexing stuff. its easy to fix but gonna take another day i guess…
Ok I’m gonna go ahead and add multi-threading support right away. I have to rethink the PageNode - PageLoader interface a little but I got it down, mostly. Still gonna put it in sooner or later might as well prepare for it right away.
Updated the thread.
I’m running on several threads now. Honestly it’s now easier to use then before. I added a custom callable where you put the actual loading stuff, but i also removed some other stuff and harmonized a lot of other stuff and removed the need for a lot of other custom classes.
Anyways, its looking up. Sorry for my relentless updating.
No need to apologize for your updates, it’s a lot of fun to watch your progress. I certainly know of a few core developers who will be thrilled to hear that:
All C++ (even in spirit) is going out the window.
In the tree generator thread you mentioned the prospect of a completely generated ecosystem. I think that's an excellent idea. Initially the individual parts wouldn't really need to be tied tightly together either, but it could make one heck of a demo. You should check out what @makeshift did with the "terrain water surface". The way this is going, anyone could create quite the amazing environment with just the click of a few buttons.