wipes sweat off Alright, gonna see that I get those scene editing tools into a proper API asap… As I outlined, currently each plugin handles the scene and opening it etc. completely by itself… We want to add a simpler API with access to mouse and camera tools etc. for typical scene editing plugins (as in you manipulate the stuff on screen with the mouse). This will also allow the tools to work concurrently on a scene (e.g. you open a scene and all scene editing plugins are available on it). Everything you can do via the SceneExplorer should be easy to add already though.
1 Like
@normen
@erlend_sh
Sounds great. I’ve created a module now, just browsing through the contributors handbook stuff, guess I’ll apply for a password to user contributions repository in the coming days 
Updated the thread.
1 Like
I put it in the trunk now updated thread. I managed to undo a few changes i did with comments mainly, and some stuff, so i had to re-do it. might have missed out on something but it seemed to work before i sent it. Just saying.
Cool, I am gonna test if it builds, actually the contrib building isn’t wired yet since beta.
1 Like
Terrain grid is not in the editor yet. I do want to add it in there though.
Right now what is holding me back is the limited amount of textures the default terrain material can use, and hooking that up with the painting tools. A texture atlas could help solve this, or possibly some other techniques.
@normen
Thank you, I hope it does, I followed the instructions as best I could. Not sure the actual java files are included tho, I just wrapped the jar in a library, which i then wrapped in a nbm. Will have to fix that otherwise.
Hmm just found the “TerrainGrid” class. That means I’ll build the “TreeLoader2D” around that (the loader that uses terrain height data to place stuff and only stores/generates xz coords).
Don’t have to worry about terrain then, awesome…
1 Like
Yeah, GridTerrain editing is not built into the SDK yet but I believe @Sploreg and @anthyon are looking into that…
1 Like
@sploreg
I see it is extending TerrainQuad. That means i can just pass a TerrainQuad for the height value stuff, whether or not its a grid don’t matter, all I need is a source of height data (used to be a function pointer in the c++ version…). Gonna assume everyone who wants to do things that way will use a single terrain or a terraingrid, and not just a bunch of separate TerrainQuad objects. Problem solved.
Also if tree placement is put into the editor it could be used for both grids and regular quads i guess. It is very convenient in every way.
You can even just pass around the Terrain.java interface, it has height access in it. Then you aren’t bound strictly to TerrainQuad.
1 Like
The original engine had a caching-system where page loading was based on camera speed and the amount of pending pages. That was suspended with multithreaded loading. Now its just based on distance from the camera. I want a more intelligent cacheing system. It will have to be prio 2 though, until the trees and grass are done…
Could use lots of work on the multiple thread system also… there are basically no priorities or mutex going on, and while its not needed right this second, a system will be needed to handle stuff like that, which is why i am considering making a “brain” to be shared by all active paging engines. One common problem is for example one paging engine relying on data from the pages in another paging engine - that might not even be generated at that particular time.
Hmm maybe I should base my paging on the LRUCache class instead of the old system? I can’t see any reason not to.
@Sploreg
Would that be ok?
Wow… there is so much stuff in the terraingrid class. I feel like those guys in afghanistan sitting in huts looking at jetplanes and rockets.
androlo said:
Wow.. there is so much stuff in the terraingrid class. I feel like those guys in afghanistan sitting in huts looking at jetplanes and rockets.
As long as you don't start a cargo-cult, I think you will be ok. :)
I could replace the old stuff within 1 day. Gonna do it y’all. No more arrays.
EDIT: Hmm… i may actually need the rigidity of the current system. Interesting stuff none the less.
pspeed said:
As long as you don't start a cargo-cult, I think you will be ok. :)
Sorry. You're soon gonna watch me paint Sploreg on my chest, worshiping his posts and terrain grid.
Essentially, changing to use the LRUCache class would basically mean changing a list into a linked hashmap and encapsulate some cache-related stuff and remove it out of the update loop. This is the kind of stuff im pondering now while i work with the trees. Could save me a lot of time
EDIT: We use the same system, essentially, so most of the code is already there, just needs to be shoved around some.
Sure go ahead and use the LRU classe, it seems to serve its purpose quite well.
1 Like
Thank you.
Module problems. I added the lib to a module so it could be sent and installed via update. I now try it, but it doesn’t seem to work. I don’t know how to access the contents (the actual jar). It is a module with a library descriptor in it, pointing to the jar.
Is someone used to this and know how to do it and could help me out?
EDIT: The whole point of using the nbm format for this thing is to make the lib accessible through the update center. It does not add anything to the SDK.
updated
This is good stuff. I can certainly use the LRUCache class, and implement it pretty much as it is done in TerrainQuad. It just needs some tweaking to be able to handle fade transitioning and stuff, but that code can just be transfered from my current code into the runnable (already done).
This takes care of another thing automatically - ensuring all different detail levels (different geometry) each page contains are loaded at the same time.
The Paged Geometry code is basically all been replaced now lol. Just a few lines left here and there. I guess it was pretty outdated after all. The tree and grass-generators uses more of it tho.