Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - AW999

Pages: 1 [2] 3 4
16
Support / Re: Performance issues - polys and billboards
« on: March 04, 2010, 09:39:34 pm »
There's not much to do:

Code: [Select]
yourObject.setBillboarding(Object3D.BILLBOARDING_ENABLED);


  Is there a distance setting (the distance at which the object is billboarded), or do you have to run a loop thru all the objects for each frame and set each one based on its current distance from the camera?

17
Support / Re: Performance issues - polys and billboards
« on: March 04, 2010, 09:18:56 pm »
Is there are a convenient bit of sample code for using billboarding?  I haven't been able to find much for some reason.

18
Support / Re: Performance issues - polys and billboards
« on: March 04, 2010, 02:17:44 am »
Based on that, it would have the same number of polys as it usually would.
How do you figure?  Just because you rotate a 2-poly Object3D so it always faces the camera, it still only has 2 polys.  Use the appropriate texture, and Voila - you have your simulated volume.

  Ok, I looked at the comments in this thread again and it turns out I misinterpreted a few things.
 

19
Support / Re: Performance issues - polys and billboards
« on: March 04, 2010, 12:58:16 am »
I thought the whole point (the only point) of billboards was to improve rendering speed by displaying a static bitmap image of the object beyond a defined distance?  Otherwise, what's the point?
The point of billboards is to simulate a volume of some kind with only two polygons, vs the multiple polygons that would be required to do the same without billboarding.  Billboards are useful for all sorts of things, including plants and trees, spheres, smoke, explosions, glowing effects, etc.  I use them all the time myself.

  But Egon Olsen just said that a billboarded object is just a normal object except "It's just rotated in a way that it always faces towards the camera."  Based on that, it would have the same number of polys as it usually would.

20
Support / Re: Performance issues - polys and billboards
« on: March 03, 2010, 11:44:14 pm »
A billboard IS an Object3D. It's just rotated in a way that it always faces towards the camera. So in your scenario, i don't think that this will do any good unless i got you wrong somehow.

  I thought the whole point (the only point) of billboards was to improve rendering speed by displaying a static bitmap image of the object beyond a defined distance?  Otherwise, what's the point? 
Are there any plans to implement bitmapped billboards? 

21
Support / Performance issues - polys and billboards
« on: March 03, 2010, 11:20:08 pm »
I assume that the frame rate will be far higher if the terrain is formed from 'billboarded' objects rather than quads (two polys) ?  I.e., let's say you start with a typical terrain mesh formed from quads which have a flat 'grass' texture, then replace each of those with a billboarded 3D object representing a tuft of grass with billboarding set for all but the closest distance (or even when right in front of the viewer). I would think that since a 'billboard' is just a bitmap image, it should be faster to render than a polygon, hence a landscape made up mostly (or entirely) of billboard images should have a higher frame rate than a polygon mesh? Or am I missing something?

22
Support / Re: Reflections in water ?
« on: February 26, 2010, 01:15:05 am »
I've been hoping for a feature like this, since it adds a lot of realism.

BTW, since you said you were busy, I assume that means you aren't able to devote full time to JPCT? 

23
Support / Re: Using separate objects for each terrain quad?
« on: February 17, 2010, 08:59:51 pm »
If varying the colors is the only issue, just create a texture containing all 256 levels from black to white as small 2x2 quad and assign them to your polygons using a second texture layer with color modulation and u/v coordinates located in the middle of each 2x2 quad. That should allow you to use different shades per quad while still using one texture. I think it will still look tiled though

  I assume, then, that there won't be a performance drop so long as all the quads use (a portion of) a single texture graphic, even if they each use different parts of that texture by setting the UV coordinates to a different part of the texture?  Hence each quad could effectively have a different texture, so long as all the texture 'tiles' are in the same big graphic?  Or am I misunderstanding?  In your previous note you had said that performance drops with 'state changes' from one poly to the next, but I'm not sure what you meant by 'state changes'.

24
Support / Re: Using separate objects for each terrain quad?
« on: February 16, 2010, 10:41:58 pm »
With quad, you mean a real quad consisting of two polygons? If yes, then this will be the absolute killer for performance...don't do this. Try to create chunks of geometry as large as possible to try to minimize state changes, i.e. use one set of textures on as many polygons as possible. If you want to use different colored textures for each quad for whatever reason, merge them into one larger texture instead.

  Yes, I meant a quad consisting of two triangles.  I need to generate terrain which has both a realistic degree of variety and also smooth transitions. I've been adapting my procedural terrain algorithm (which I had previously been using for a voxel-based program), in which you just have a plain grid with an elevation and a unique color for each voxel, hence smooth transitions from one voxel to the next. I thought I could just treat each grid point as a quad (or a vertex on a quad) and then add 3D plants, trees, etc, as needed.  But this requires varying the color slightly from one quad to the next. 
 So you're saying it's actually better for performance to use Terrain Demo's method of having two meshes and blending them, thereby duplicating each quad?   If so, how do I blend more than three textures, or tint them to produce smooth transitions?
 

25
Support / Re: Using separate objects for each terrain quad?
« on: February 16, 2010, 12:37:48 am »
I guess I should have explained my question more clearly. If I need X number of quads in the terrain mesh, what is the difference (in terms of memory usage, speed, etc) between a) having a single object with X quads, versus b) X number of objects, each consisting of one quad?

A related question: I'm hoping to produce smooth variation from one quad to the next by either: a) giving each quad a single color which varies only slightly from neighboring quads (e.g., a smooth progression from green to tan), or b) better yet, tinted textures which use a combination of a texture with an overlaid color, where the color would vary slightly from one quad to the next as in option A.
From what I can gather from the manual, option B can only be done by using setAdditionalColor to 'tint' an entire object (in which case each quad would have to be a separate object), and option A could be done by generating a 1x1 texture from a color using AddTexture(width,height,color). Correct?

26
Support / Using separate objects for each terrain quad?
« on: February 15, 2010, 12:48:31 am »
Is there any disadvantage to using separate Object3D objects for each quad in the terrain rather than using a single object with a large number of quads?  I.e., would it use a significantly greater amount of memory or take longer to generate the terrain, or some other disadvantage?
 
 

27
Support / Re: Strange terrain problems
« on: February 15, 2010, 12:38:46 am »
As i've already said above, you can try to increase the near clipping plane, albeit this might not help much in the distance. And ensure that you are really getting a 24bit zbuffer at least...this should be visible in the log at initialization stage.
Apart from that, i don't see many options left. If the accuracy isn't high enough, it's simply not high enough. There's no magic switch to increase it.
Which graphics hardware are you using and how is your water plane build? Is it one large quad or more tessellated? If it's one large quad, i may help to tessellate it some more.
If you look at my terrain demo, you'll notice slight z-fighting too if you move further away. I've just adjusted the far clipping plane and the fog in a way, it's not that noticeable.

  I tried increasing the NearPlane value back to the original value in your terrain demo (100), but that didn't seem to make any difference. I also tried tessellating the water plane more by quadrupling the number of quads to 80x80, but that had no effect other than slowing the framerate to a crawl.
I don't think it can be the hardware, since Wurm Online doesn't have any flickering shorelines on my machine despite clearly using intersecting land and water planes. (Correction: Wurm does have flickering shorelines on my machine)
I wasn't able to confirm whether it's using a 24bit zbuffer; where in the log should it give this information?

















28
Support / Re: Strange terrain problems
« on: February 14, 2010, 07:28:09 am »
From what i'm seeing of your screen shots. It looks like the ground plane is near the same height as your water. Increase the elevation of the vertex points so the terrain is more terrain'y with hills, mounds and lake/river drops. Then see if there is the same graphical problems. As it is, it just looks like the ground is too close to the water which is causing the graphical problems.

  The screenshots show low-lying land near shallow lakes, but there are also hills and deeper lakes in other parts of the terrain.  I need to have both types of landscapes to be realistic - there are plenty of flat areas of land in real life.
  I can partly solve the z-conflict problem by replacing the water-plane with 'local' water polys only in those areas in which the water is above ground level;  but that would still cause shorelines to flicker. Surely there must be a way to get rid of the problem - there are plenty of programs which clearly use intersecting land and water planes to produce shorelines, without any flickering.

29
Support / Re: Strange terrain problems
« on: February 13, 2010, 11:54:53 pm »
No, setSortOffset() doesn't have an effect. Why isn't increasing the distance between ground and water surface an option?

   As in your original terrain demo, the water plane has to intersect the terrain at various points to form the shorelines for lakes, and of course the distance between the two surfaces is going to be fairly small near the shorelines.

30
Support / Re: Strange terrain problems
« on: February 12, 2010, 01:20:38 am »
The screen shots show z-fighting, i.e. the zbuffers accuracy isn't high enough to separate the ground and the water, because they are too close together. The reason why this increaes when moving the camera further away is, that on most hardware actually not z will be stored but a/z (with a being some scalar). That's pretty accurate close by but the inaccuracies increase if z increases, i.e. accuracy isn't linear in camera/clipping space.
You may try different things: a) Move the water away from the ground. b) Decrease the far clipping plane. c) set Config.glIgnoreNearPlane to false (the docs of this switch are reversed, i'll correct this) and increase the near clipping plane (this will move the scene close too the camera...so don't increase it too much, or you'll end up with a very distorted scene).

   I had increased FarPlane, but decreasing it back to the original value didn't help things any. The other options don't look feasible.
 Would setSortOffset have an effect? 

Pages: 1 [2] 3 4