Quote from: EgonOlsen on January 02, 2010, 08:21:22 PM
No, that doesn't matter. If you are using the software renderer, it may cause a slight drop of maybe 5% at max, but nothing to worry about. Of course it's getting slower when more geometry is in the view. Maybe that was the problem in your case.

  I don't think that can be the cause, because I just performed the following tests: 1) I ran it with all the terrain chunks in their proper positions but also in the view simultaneously - by zooming back far enough to have a view of all of them - and yet I was getting framerates of over 60.  2) I placed all of the terrain chunks at the same location and then ran it again, and the framerate dropped to 10 - 17 (!). 

The framerate for one of my programs slowed to a fraction of its earlier value when I (mistakenly) placed all the terrain 'chunks' at the same location - which wouldn't be a problem (easy to fix) except I'm wondering whether any overlap between objects would always slow the framerate, such as if I place trees right on the surface of the terrain, thereby causing a slight overlap for each. If so, this would cause severe problems unless the objects are adjusted so they have a slight gap between them.

Quote from: EgonOlsen on December 23, 2009, 07:27:26 AM
I will do later. Currently, i'm still optimizing some parts of jPCT for it. It's a pretty good test case...

  When are you going to put it online (via an applet or whatnot) so we can see it ?   

In order to have a fairly large map, I need to have only a portion of the terrain in memory at a given time, and then update it as the user moves. I'm wondering whether it's better to : a) have a single object for the in-memory terrain and then add and subtract triangles from the sides as the user moves (is it possible to subtract triangles?); or b) divide the in-memory terrain into several chunks, each of which is a separate Object3D, and then when the user moves too far in a given direction, reposition these objects while deleting the chunks which are now well beyond the viewable area and adding new chunks on the other side. c) Is there a third option?

Could you put an applet version of it online so we can see it, or a downloadable jar file ?
(I mean so we can see it in action....)

Wow.  What method are you using to generate the terrain, and how far does it extend in any given direction?

Quote from: EgonOlsen on December 21, 2009, 12:29:42 PM
...using which renderer?

  Well, ideally I'd need my applet to be as widely compatible as possible, so presumably all of the rendering modes.

Since the built-in fog effect apparently works well only when the fog is 'black' (according to one of the files or wiki articles), what's the best way to produce atmospheric haze - i.e., making distant parts of the landscape look bluer? 

I've been looking at the examples which come with jPCT, and wondering whether it's permissible to use them (specifically CarTest) as the starting basis for projects? I.e. modify the code for a new project, including commercial ones?

Quote from: EgonOlsen on December 04, 2009, 04:51:46 PM
What do you mean by "handle"? Create or render it? For creation, have a look at this thread: http://www.jpct.net/forum2/index.php/topic,1343.0.html

  Thank you - that should be a big help. But if I'm wondering if there's any other way to do it, such as a 'heightmap' type 2D array separate from any 3D polygon objects?  I remember coming across a webpage that seemed to imply that something of that sort was possible, although I may have misinterpreted.

Thank you for your reply. What's the easiest way to handle terrain?  I thought I read somewhere that there was a special feature for it, but I can't find the page now.

Does JPCT allow a program to generate 3D objects at runtime?