Using a dynamic list makes sense for dynamically collecting data, no? 
Just use an ArrayList if thats not the case already and you need to access single items in the list by index.
1 Like
@EmpirePhoenix
That would be very good, I’ll try that first, thx. I have a goal to delegate as much as possible to the API.
@Normen
It does make sense, but I am not dynamically collecting data, I know exactly how many objects i need to batch before i start batching. The optimize method had collections with empty constructors all over, so i was afraid it would add unnecessary overhead. Sry, guess I wasn’t clear about what the actual problem was. And also I don’t seem to know java Collections as well as i should. I’m working with very large numbers, gots to cuts the corners everywhere.
Btw. in the original PG lib (and C++ in general) fixed-size arrays are used whenever possible, but that may have changed the last few years I guess (there’s a replacement for Vector maybe)… I’m sort of catching up as i go along now lol
Ooooo some nice progress. The paging system is almost done. I just tried loading some trees and it generated the page grid, set the various managers correct etc. Just some erm problems with the cache system now. Seems pages can be both loaded and not loaded at the same time (they’re both in the loaded and pending lists)…
When I worked these things out I’m gonna take it on a test run and fraps it with a bunch of data showing in the GUI.
uuhhhh its in the GeometryPageManagers update method… the nastiest method in the nastiest class in the entire lib.
EDIT: haha solved it.
EDIT: damnit, now i can’t move.
EDIT: oh well, i’ve been debugging it some now, seems the biggest problems are found in the treeloader3d/batchpage classes, and i just recently finished those. It’s where i try and integrate with jME the most, and replaced lots of the original code. Everything else seems to run along smoothly.
Sorry for writing a bunch of un important stuff here.
EDIT: Yep, just as i suspected. It mostly has to do with integration. Bounding boxes, geometry etc. That means the paging engine is done, and now I’m doing mostly integration stuff.
1 Like
A status update if anyone wants, before bed time.
The tree-meshes are now attached/detached properly from the scenegraph depending on the distance from the camera.
The tree-pages are cached then load as they should. But they do not unload properly. I guess its because of some crap in the update method (a botched formula most likely ).
I made a statistics gatherer that shows info about loaded pages, visible pages etc on the screen. I will have those stats up when i run the demo.
A bunch of stuff to do still, but I have to say it looks pretty good, even at this point. I’m becoming more and more confident this will work out nicely.
1 Like
MOAR VISUALS!
uh, eherm, please excuse me. The frequent updates are very appreciated. I think you’ve got a lot of people very excited, myself included 
ok but i have to fix the loading stuff first
loading/unloading works now. it was simple, PG used an int to measure the time a page had been deactive (outside of loading distance) in milis, and i kept feeding it the tpf variable.
There is still lots of debugging to do in order to get the visibility calculations to work correctly. This mostly has to do with bounding boxes, and is easy to solve once the geometry batching process is firmly in place.
The thing is, loading & caching is based on page grid data (the dimensions & locations of the pages), whereas visibility & lod transition is based on the bounding boxes of the batched clumps of trees within the pages, so if there’s one tree in a page, the page could be loaded but not visible, because the bounding box of the tree is outside of the far visibility range.
Haha.
1 Like
Work is piling up now, gonna focus on that for a few days and get back to programming in the weekend. Hopefully I’ll have a nice demo sometime next week.
Seems very nice.
Maybe my plugin may become useful for you. I am working on a realistic tree generator based on the arbaro project. Currently no LOD meshes but I am working on that.
Keep up the good work.
Hey, I saw that actually and was gonna contact you myself. It’s quite a weird coincidence.
I think it would probably be a fun idea to link this together sometime in the future. Do like a speedtree thing where instead of using a couple of models, storing only coordinates, rotation and scale at each datapoint (like I do now), you random some sort of data for your lib and generate trees that way.
I know some guy in the Ogre forums started a project like that with ngPlant and the actual PG, but it was discontinued i think… not sure what that means tho hehe.
Finally. Loading finally works as intended. I think a dynamic loading demo may come a bit sooner then expected.
EmpirePhoenix said:
Don't use billboards, there is a far more intelligent approach possible:
Use gl_point as they are faster than any triangle based one. However point always look directly at the cam, so you need to correct the perspective in the shader then.
Here is a explanation of what i mean, only it is for mass bullets where tehy use this instead of grass. I think it will come in handy for grass as well.
http://www.shmup-dev.com/forum/index.php?topic=1870.0
Hmm i think this can be applied to tree impostors as well. If a texture rotation matrix is used, I think it could in fact make PGs impostor textures a lot lighter and easier to generate... This was a good article, thanks again.
I had to mess around quite a bit with this point sprite stuff because i suspect a driver bug makes it impossible to use gl_PointCoord… Luckilly my crappy, crappy laptop integrated intel hd crap had a new driver available… i am hoping it will fix things.
and it didn’t
may be something else. gonna try some stuff.
Does the JME point sprite test run?
1 Like
@pspeed
im guessing it will. I got fixated on the driver thing because i found out some other person with an intel card had a similar issue. I’m pretty sure it worked well with particles. Gonna try some more stuff.
EDIT: No it seems to be something wrong with gl_PointCoord never changing. I have set a proper mesh type and material to use point sprites. Vertex shader does its thing:
//********************************************************
uniform mat4 g_WorldViewProjectionMatrix;
attribute vec3 inPosition;
void main() {
vec4 pos = vec4(inPosition, 1.0);
gl_Position = g_WorldViewProjectionMatrix * pos;
gl_PointSize = 50;
}
but fragment shader doesn’t:
//**********************************************************
void main() {
gl_FragColor=vec4(gl_PointCoord.s,gl_PointCoord.t,1.0,1.0);
}
All i get is large blue squares.
I believe it might be a graphics card issue after all. have had issues with other stuff before. time to get a new laptop i believe. gonna try this on another computer later…
The people i direct my stuff to often have cheap computers and crappy graphics cards. I may have to create an alternative to point sprites… gonna save this for the future and start working on the core again.
That’s btw. why i work on a crappy computer. If it works on mine, it works on everyone elses
I didn’t see the answer to this yet:
Does the JME point sprite test run?
If it does then your card can do it and it’s just something else you are doing wrong.
I ran that test and it’s and its the same thing. Sprites are not colored correctly.
I’ll just make two different systems for billboards. Thanks for the help/suggestion.