No, that’s quite sensible. The CLOD (chunked level of detail) approach is only a tweak on top of the geomip-mapped approach and that seems to be one of the most popular approaches recently.
IMO ROAM is a doomed approach for HW acelerated rendering. No point in tying up the CPU when the HW can handle the data just fine.
Thanks for the answer.
0.0.14a is up.
Look at this cool screenshot instead of playing it, as performance is bound to be horrible, but I’ll let further optimisations wait until later.
I’ll keep the server up for a couple of hours from posting this, just so you know.
Why did you have to tell us not to download and play it? Now I just have to 
Downloading now using my lovely 56k connection (I miss my broadband god dammit!).
EDIT: The screenshot is cool and very nice looking… ;D
Hate being a nitpick, but the good 'ol “can’t change display mode” problem is back - so much for trying to get my system to crawl 
uhoh.
Got a stacktrace or two for me?
I should learn to just leave code alone once it works.
sure:
java.lang.UnsupportedOperationException: Cannot change display mode
at java.awt.GraphicsDevice.setDisplayMode(Unknown Source)
at com.wurmonline.client.WurmClient.initGraphics(WurmClient.java:138)
at com.wurmonline.client.WurmClient.init(WurmClient.java:41)
at com.wurmonline.client.WurmClient$4.run(WurmClient.java:253)
java.lang.reflect.InvocationTargetException
at java.awt.EventQueue.invokeAndWait(Unknown Source)
at javax.swing.SwingUtilities.invokeAndWait(Unknown Source)
at com.wurmonline.client.WurmClient.clientTick(WurmClient.java:224)
at com.wurmonline.client.WurmClient.run(WurmClient.java:172)
at com.wurmonline.client.WurmClient$4.run(WurmClient.java:255)
Caused by: net.java.games.jogl.GLException: Error making context current
at net.java.games.jogl.impl.x11.X11GLContext.makeCurrent(X11GLContext.java:138)
at net.java.games.jogl.impl.x11.X11OnscreenGLContext.makeCurrent(X11OnscreenGLContext.java:108)
at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:156)
at net.java.games.jogl.GLCanvas.displayImpl(GLCanvas.java:179)
at net.java.games.jogl.GLCanvas.display(GLCanvas.java:84)
at com.wurmonline.client.WurmClient$3.run(WurmClient.java:228)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Linux
java.lang.NullPointerException
at com.wurmonline.client.gui.WorldView.gameTick(WorldView.java:525)
at com.wurmonline.client.WurmClient.gameTick(WurmClient.java:215)
at com.wurmonline.client.WurmClient.run(WurmClient.java:196)
at com.wurmonline.client.WurmClient$4.run(WurmClient.java:255)
Yeah, it’s the same thing… But I’ve FIXED that. :-/
(or worked around, rather)
Sometimes I just don’t understand java.
For me it connects to the server, the screen goes blood red, and the error messages state “GL: Invalid Enumerant (1280)”. I get 1 fps on my black and red screen. Specs:
PIII 733 w/512MB
GeForce2 GTS w/32 MB
Enumerant 1280 seems to have something to do with some nvidia extensions… Can’t find specifically what it is, though.
Oh, and Wurm requires OpenGL 1.4 (uses automatic mipmap creation right now, and will use multidrawarrays later on), so make sure you’ve got the latest drivers.
I have the latest as of March, so that should be up to date.
Ok, then your system isn’t one of the target systems.
;D
Hey, what was that sound? Oh, we just lost half our customer base!
0.0.15a is up. (settings, loginscreen, optimisations)
That pretty much wraps up the first version of the client.
Now I implement picking and basic world interaction.
Looking really nice… The distant hills look much better than the previous version I tried out.
My friend asked how you built the landscape and suggested using real-world elevation data… apparently it is easy to get.
Thanks. =)
I found some sites with heightmaps, and got about halfway through loading them before remembering that we’re supposed to have “random” maps.
Each server is going to run it’s own map, and the maps are going to be way too big for us to make them manually.
Oh, ok, we’re lazy.
Hey, lookin good now, i really like it.
If i may make a suggestion, i’ve seen this effect done in other games, and i think it would be very helpful in this one: When objects are brought into view, there is a sort of ‘fade in’ (i guess the transparency is brought from 100% to 0% over the course of a few seconds) and it makes it look a lot smoother walking around, than if trees and tall grass was just blipping in and out of the screen immediately. Maybe you’d could implement that when an object is made visible on the screen, it is placed in the drawing area transparant, and when the object is to be removed, it can fade away first? Just a thought.
-Chris
Fantastic vegetation. I’ve been recently looking into that. What technique did you use for the grass and trees? That’s exactly the look I wanted to go for in my app. Any pointers would be great. Keep it up, it’s starting to look fantastic.
I’ve considered that, but I’m not entirely sure how other people do that… I’d need to z-sort everything each frame, and there can be up to a thousand trees and a thousand “grasspatches” in view at the same time…
That’s 4000 multiplications and 2000 sqrts. :-/
[quote]Fantastic vegetation. I’ve been recently looking into that. What technique did you use for the grass and trees? That’s exactly the look I wanted to go for in my app. Any pointers would be great. Keep it up, it’s starting to look fantastic.
[/quote]
This could get lengthy, but here we go:
There are two similar systems in place, one for the trees and other “big” items (like buildings and so) and one for the tile decoration.
Whenever the user moves to a new tile, the engine scans the closest tiles with a simple for (x=-n; x<n; x++) for (y=-n; y<n; y++) for trees.
For each tile that contains a tree, it calculates how far away it is from the tile the user and how many tree neighbors it has.
If the ratio of neighbors versus distance is over a certain threshold, AND the tree is on an “odd” tile (odd==((x+y)&1)), that tree is ignored. (effectively “trimming” dense forests when they are far away that you don’t notice the difference)
Then a new Random is created with xsomePrime+ysomeOtherPrime as the seed, and a new Tree object is created based on that Random object. This will ensure that a tree on a specific tile will always look the same without me ever having to store that information. Information like offset within the tile, rotation, size and color is generated.
That Tree object is then added to a SortedSet, sorted by distance.
The rendering loop iterates over the set, checks if the tile the tree is on is visible, and renders the tree if it is. The first trees up to a certain limit are rendered in high detail mode (right now just a cross of three polygons. Will be full models later), and the rest are rendered in low detail mode (billboards). When more than the maximum number of trees has been rendered, the iterator exits.
Tile decorations work almost the same, with the exception of the texture of the tile deciding what types of decorations will be added to it. The amount of decorations added to a tile depends on the distance to that tile, with the biggest decorations being added first.
I’d give it a try and see how much performance it will cost. In my experience, z-sorting doesn’t take that much time and will make blended stuff look better…
It WOULD be nice… The grass would look a lot better if it was blended for real instead of just “clipped” as it is now.
But I’ve got a lot of intersecting polygons. Like ALL trees.
/me is jealous of all others being able to see this beautiful world
Maybe I should pray to “Nick” so that he fixes the linux bug by some of his “godly powers” ;D
