On a TerrainPatch there is a method called getLod. The lack of documentation for this engine is irritating, does anyone know what this method means? I know lod = level of detail but I still don’t know what that value means
Why don’t you explain what you are really trying to do and maybe we can point you in the right direction.
I have a simulation that changes the terrain, but of course there are many data points to update. I want to only update the terrain that is visible and at the correct level of detail. In order to do that I need to know if a terrain patch is being rendered or not based on the lod.
Each data point will update a 16x16 patch of the terrain but depending on the LOD only the 4 corners of that patch will be updated (for instance the height). But if zoomed in more the 16x16 patch has to updated. Even perhaps as you continue to zoom in, more of the vertices need to be updated until you get down to the smallest quad.
Prediction: you will want to write your own terrain paging before too much longer.
I don’t think JME’s terrain is designed to do what you want… so you will be fighting it a lot. It also does some things that I personally find kind of dumb (the edge stitching is totally unnecessary for example).
For alternative approaches, you could look at this paging library:
It just manages the grid, the background threads, and scene interaction (kind of) for you. The specific mesh generation, etc. is up to you but it would let you use more classic approaches.
The downside is that it’s not well documented. It’s reasonably straight forward, I guess… and you can see how it is used ‘in action’ here:
It manages the terrain and trees/grass in that demo but should just as easily help manage LOD “pyramids” which I think is what you are describing.
Here’s a video of the demo:
It’s not a cookie cutter solution for sure… but maybe it helps when you’ve hit bottom on JME’s terrain.
Alright, I’ll consider this since I can still use jme. I’m not looking for an infinite terrain though, it’s finite. I really don’t understand why code can’t be well documented.
We’re all waiting for you to document it.
2 Likes
I’ve found certain parts of the engine to be more well documented than others, especially when you get to working on unique things that at are more custom to your game.
There’s never a lack of help when you come to the forums though 
I didn’t write the code. I am a software developer by practice and it’s the job of the developer to write the documents, not the users of the code.
3 Likes
I agree, it is nice to see well documented code now and then
Just imagine if Oracle said this.
2 Likes
They are paid. We volunteer.
Sorry. I thought we were randomly dictating how other people should spend their volunteer time.
The code is right there. It’s not hard to understand.
Or let me put this another way. Given that documentation often takes a LOT longer to write than the code, if the choice was “write the code and document it” or “not write the code”. That developer would likely have not written the code.
…so just pretend it doesn’t exist. That would be what you are asking for anyway.
That’s pretty much what I do now if there are alternatives.
As you say though, you get what you pay for.
I mean, the contention in this thread is that undocumented code has no value. That’s just plain not true. Definitely well documented code has MORE value but there is an intrinsic value to the code itself.
The entitlement in statements like “I really don’t understand why code can’t be well documented.” is pretty thick. The statement either comes from someone who truly does not understand how much work goes into “well documented” or they are the kind of person who goes to a soup kitchen and expects the staff to hand-feed them each spoonful.
Some of JME is well documented. Some is not. I’ve suggested cutting terrain loose into its own project many times but always get arguments. Some parts of the engine we drag along, virtually unsupported.
And there is another down side to that, too. Someone looking to jump in and help might feel daunted about contributing to “the core” where as they might have no problem stepping into a separate module.
But anyway, I’ve lost that argument many times already and now what’s done is done.
1 Like
Rereading this… I wonder if maybe I’m overcomplicating it by even suggesting paging at all.
How big is your terrain and how many lowest level sections will it be divided into? Or have I misread and it’s not a pyramid at all?
Depending on size there might be other approaches that are even easier that don’t look anything like the Terrain patch stuff.
Heh, I have a different analogy, its like taking a shit and not wiping your ass afterwards. You got rid of most of the load but that little bit of extra work left to be done makes ALL the difference in the world.
Grin.
The combo of source + wiki + forum does make up for any lack of documentation though.
The forum search is as good or better than anything I have read in most docs for any project. Prior to jme I had never read the source of anything but now I am addicted to it. I learn a lot of new ways to do things which helps improve my coding skills.
I’ve spent twice as many hours documenting Lemur as I have writing it. And I don’t think folks consider it well documented.
So you are all grossly undervaluing the amount of time it takes to write documentation.
But I’m glad to know that code without documentation is basically shit.
I was thinking it was being over complicated. I’m not making a pyramid no. I said 4 corners because if you zoom out as far as you can go on a terrain the lod is at it’s minimum before the mesh no longer is in view based on the distance of the camera, that quad is rendered at that level. (I’m trying my best to explain through typing and no images). If you zoom in though to the next level of detail you would indeed just see 4 vertices spiked up and the rest of the quad would be, I guess at 0 to start. What I would want to do is continue updating the number of vertices that come into view.
If a patch is 64x64 and you are zoomed out far enough for it to be rendered as just a single quad with just 4 vertices then the rest of the 4092 vertices will not be updated (there’s no reason to it’s out of view). But as you zoom in to the next level, instead of 4 you have 8 to update. then 16, then 32 and so on until the max level of detail is being shown. That’s all I want to do.
Or let me put this another way. Given that documentation often takes a LOT longer to write than the code, if the choice was “write the code and document it” or “not write the code”. That developer would likely have not written the code. …so just pretend it doesn’t exist. That would be what you are asking for anyway.
I completely disagree with that. It takes the implementer less time to document code they wrote than a person coming in who didn’t write it and then tries to write the docs or understand it.
I understand that not all code is going to be documented, and I do read the internal black box I’m working with to get an idea of how and why it’s there.
But not documenting at least some level of detail about why it’s there is nice, I care mostly about the types of input and their boundaries more so than the actual description. It helps obviously and it speeds up all the developers projects using that code.
Self documented code is obviously better with maybe a small short description to remove any possible strange ambiguous code the reader would come across, because you also have to maintain the docs when the code changes, just more work to do. Writing code that needs documentation is shit code though. So no not all code that is not documented is shit.
re: “the rest of the 4092 vertices will not be updated (there’s no reason to it’s out of view).”
Is updating the view expensive? Like you have to do lots of calculations or something?
…because updating the mesh itself is not necessarily that expensive and there are ways to make it even faster.
That’s why I was wondering about the size/resolution/etc… maybe there is a simpler way.