landscape viewer applet

Started by danmeany, October 21, 2003, 04:24:57 AM

Previous topic - Next topic

danmeany

I am thinking about cobbling together an interactive applet viewer for some large dataset public domain elevation data from the USGS (for the curious it's in ".BIL" format - an integer raster).  Basically I am just grabbing sections out of the file and moving around in the canyons etc and viewing it from different angles, like a virtual hiker, maybe overlaying some satellite vegetation coverage data if i get carried away.  Do you think jPCT would be a good choice for that, and/or do you forsee any pitfalls?  Or has someone already solved this problem...:)

EgonOlsen

Do you just want to grab some parts of the file and display only those, or do you want to stream the file from the server while the camera moves? Anyway, it should be possible with jPCT but the later case will require some streaming on a per object/block base and it may limit octree usage. Or in other words: It's not an easy thing to do, i think.
The former case is much easier. Load your data using with your own loader, maybe setup an octree for it, place the camera and some lights and you should be done (well...almost... :wink: ). A VERY basic example of a landscape can be found in the example-dir that comes with jPCT.
Keep in mind that you are limited to the software renderer when using jPCT in an applet. This is due to the design of LWJGL (the OpenGL binding jPCT uses) and the applet's sandbox.

danmeany

thanks for the helpful reply.  i am not going to stream.  they'll just have to wait while the applet downloads with the 40M of data inside the zip, then it will be fast after that while they are using it, or so i tell myself :)  And the software renderer is no prob.  The terrain demo runs at 7 fps on my old 200mhz laptop, which is fine for this purpose.  So i guess it will work with the MS VM and Sun plugin, blah blah?  do you know if not using BufferedImage in 1.1 hurts performance terribly?  and do you cull stuff in the line of sight but far away?  if so i will make the background mist colored and it will be fine otherwise i might have a prob since there is alot of terrain in any direction.

EgonOlsen

Using a MemoryImageSource in 1.1 instead of the BufferedImage is not that much of a performance problem, so don't worry about it.
jPCT clips (the software renderer culls to be exact) on the far clipping plane (can be set in Config). There is done some gross culling on a per object and per octree-node base, so if you decide to use octrees, the culling will be very fast on that plane, even if large portions of the landscape are not visible. If you want to fade out the landscape into another color than black, you need version 0.95 (to be released...) to make that effect look good.

danmeany

Sweet.  And one last thing - if World and it's all it's potential children are java.io.Serializable, then I can pre-compute it and save it off to be able to quickly reload it later....

EgonOlsen

Quote from: "danmeany"if World and it's all it's potential children are java.io.Serializable, then I can pre-compute it and save it off to be able to quickly reload it later....
I'm not sure if i really want to do that, because i don't know much about this topic (i never actually cared about it). Not that it's a hard thing to add but...can you deserialize with 1.1 what has been serialized with 1.2/1.3/1.4 and vice versa?

danmeany

I was under the perhaps naive impression that if all the objects' version ids were unchanged it would work.  And if there are awt classes in World that changed it would be a prob.  (Now that you mention it though i wonder if the applet's securitymanager might be disinclined to let me do it since it bypasses teh constructor.)  i like Serializable for *local* app caches still - saves load time and is a big programmer conveience to save state between vm instances.

Hmm, looks like it might or might not work across jdk versions...
http://java.sun.com/j2se/1.4.2/docs/guide/serialization/spec/version.html#wp4602  

i guess if an applet gets an exception when deserializing (old vm), i can revert to recomputing it.  so it would run fastest on the latest sun plugin since that vm is what i would use to serialize it, if it works at all.

EgonOlsen

Ok, i think i'll do a special version of 0.95 for you to test this and if it works out well, i'll add it to the "normal" version. I hope to get this done within the next week.

danmeany

thanks, i'll give it a shot.  it should be useful with non-applet apps in any event - e.g. downloading a World instance over a web service as an SOAP attachment or something.  I wish Sun had made all classes Serializable (and even Marshalable) by default...

EgonOlsen

I finally uploaded a version for you to test. This is not a full release, just a pre-release of 0.95 that includes only the javadocs and the jpct.jar.
It can be found here: ** edit: Link removed, download the latest version of jPCT instead ** Not everything implements java.io.Serializable (things like Loader or Primitives for example don't...it just doesn't make sense for them).
Please let me know if and how it works, so i can add it to the next release.

danmeany

thanks for the test code.  I tried it out and sent some detailed feedback to hostmaster@jpct.net.  It's not essential to what I'm doing, but it sure helps...