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 - EgonOlsen

Pages: 1 ... 789 790 [791] 792 793 ... 800
Support / landscape viewer applet
« on: October 21, 2003, 06:18:08 pm »
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.

Support / OpenGl and applet
« on: October 13, 2003, 06:38:51 pm »
Well, i don't know for sure. It *should* work that way, but i never tried it. For deploying applications that use LWJGL ( (as jPCT does for OpenGL support), i suggest to use Java Webstart instead.
However, you may give the signed applet approach a try, but even if it works, it will never render into the applet itself, because LWJGL can't redirect its output into an AWT/Swing component. That the design of LWJGL..nothing you can do about that, i'm afraid.

Support / Portal
« on: October 05, 2003, 04:43:44 pm »
No, there isn't such an example yet. The basic idea is, that you assign each triangle of the main world (the "level") to a specific sector (by using the appropriate addTriangle()-method) and then build portals between them using the methods in Portals. You then have to enable portal rendering and call build() on this level to create the sector information out of the triangles' sector information.
The problem with all this is, that you have to place the portals by hand and assign the sector numbers on a per-polygon base. You can't simply use 3D-Studio or whatever to create your level.
To fight this problem, i added the XML-format loader to jPCT. This format can handle portal information, but the docs for it suffer. There's some info about it here: and the DTD can be found in the "doc/manual" directory of jPCT.
One last thing: Even if portals are great for software rendered indoor scenes (because they reduce overdraw so much), i'm favouring octrees nowadays. They are much easier to use and more flexible...but they don't help in reducing overdraw though.
Hope this helps somehow.

Support / Object3D.addChild();
« on: October 04, 2003, 12:55:25 pm »
After thinking some more about it and doing some tests, i discovered that there could be another problem: Imagine a maxPoly of 10 and 11 polygons that are exactly the same (same size, same orientation, same transformation, i.e. lying onto each other) that case, the spacial subdivision will subdivide and subdivide to get the polycount of the node down to 10 or lower but that will never happen (because jPCT doesn't split polygons to fit into the octree). This is not the only situation where this may happen (but it's simple to understand using this example), so maybe this is what happens to you.
I'm not quite sure what to do against this, i.e. how to detect this case. In your case, i would still say: play around with should fix the problem. I'll also add a maxDepth to the constructor for the next version that takes care of the recursion not going too deep in these cases...but i'll also try if it's possible to avoid the problem at all.

Support / Object3D.addChild();
« on: October 04, 2003, 12:25:17 pm »
You are trying to create the octree using a maxPoly-value of 12. The OcTree is build using recursion and if the recursion gets too deep, the stack will overflow. This is what happens to you here. I suggest that you use a maxPoly-value larger than 12 (try 100 for example). 12 seems to be very low even if the VM wouldn't puke on it. An OcTree with too few polygons in each leaf isn't efficient any more. Take the fps-demo as an example: It's using a value of 100. If i'm using 10, the tree gets so big, that traversing it every frame costs more time than it saves and the frames/sec are going down by around 20%.
Play around with maxPoly to find a good (and working  :wink: ) value. I think i'll add a "break if recursion gets too deep"-option into jPCT to avoid this problem in the future...i planned to do this anyway.

Support / Object3D.addChild();
« on: October 04, 2003, 02:05:49 am »
Yes, a dummy object should never be added to the World. You can do it though, but it doesn't make much sense. The basic processing goes like this:

Iterate through all visible object in the world, calculate the object's transformation matrix by recursing through its parents, transform the object using the generated matrix, render the object.

If you don't add the box-object to the world, nothing will be rendered at all. The dummy object lends its transformations to the box-object. It doesn't cause the box object to be rendered. jPCT doesn't care if an object has childs, it just looks at the parent(s) for getting the transformation hierarchie. Maybe it's clearer if you use box1.addParent(levelObj) instead.

Dummy objects serve a single purpose: They lend their transformations to their childs. That's usefull for connecting objects transformation-wise. They are not something like nodes of a scenegraph, as jPCT isn't a fullblown scenegraph just takes some ideas from the scenegraph concept.

Hope this helps.

Edit: here's another thread dealing with object hierarchies:

Support / Selection Mode
« on: October 03, 2003, 03:16:32 pm »
Basically, it's used like this:

Code: [Select]

SimpleVector ray=Interact2D.reproject2D3D(camera, buffer, mouseX, mouseY);
int[] res=Interact2D.pickPolygon(theWorld.getVisibilityList(), ray);

if (res!=null) {
   Object3D pickedObj=theWorld.getObject(Interact2D.getObjectID(res));

This has to be done after calling renderScene(). The docs for Interact2D state that it has to be done after "rendering the image", which is misleading. The image doesn't have to be drawn into the framebuffer yet, you just have to make sure that renderScene() has been called before. I'll correct this flaw in the docs.

Support / Selection Mode
« on: October 03, 2003, 03:14:00 pm »
It's a geometrical approach using a ray-polygon intersection test. I should really include an example of how to do it exactly in jPCT...
The object has to be "selectable" (see setSelectable() in Object3D) to be picked. None-selectable objects will still act as a "block" to the ray, i.e. if the object to be picked lies behind an object that is not selectable, the ray will still be blocked by that object and no object will be returned as picked.

Support / Selection Mode
« on: October 03, 2003, 03:08:09 am »
Why do you want to implement your own picking? There is picking in jPCT (have a look at the Interact2D class). Does this not satisfy your needs? If it doesn't, please let me know what you are missing.

Bugs / jpct 0.94 bug (2)
« on: September 29, 2003, 07:43:54 pm » are right! The problem is the same like in the JAW-loader. Making such a dumb mistake once is one thing, but making it twice really hurts...
Anyway, i'll fix it in 0.95. The remaining formats shouldn't be affected by this problem, because they are either binary (MD2, 3DS), are using a different parser (XML) or i don't care about them anymore (PCT... :wink: ).

Support / 3ds Loading
« on: September 29, 2003, 06:43:05 pm »
Quote from: "jtxx000"
What 3D program do you use to do your 3D models.
Actually none at all. I'm using freeware models to test the engine. I'm not writing a game with jPCT ATM, so i don't need to model my own stuff. Some years ago, i've used a version of 3D Studio (version 4 i believe) to make some models, but i wasn't very good at it... :wink:

Support / Re: 2 questions
« on: September 28, 2003, 11:59:56 am »
1) Does the openGL render works with Linux and other operating systems?

It should. There are binaries of LWJGL for Linux or you have to compile it yourself. Have a look at the LWJGL homepage at I never tried it though because i don't have a system running Linux (just FreeBSD... :wink: ).

2) Is there a set-method to change the samplingmode?
You mean switching between under-/over- and normal sampling without constructing a new FrameBuffer? No, there isn't because each change of the used mode actually requires the construction of a new FrameBuffer (because the backbuffer as well as some minor things are different everytime). Encapsulating this in a innocently looking setXXXX()-method doesn't express this well enough IMO. I promise to have a second look at this decision though.

Bugs / jpct 0.94 bug
« on: September 27, 2003, 05:28:58 pm »
VERSION is final static, so if you compile your application against 0.92 (for example) and are simply replacing the jpct.jar with a newer version without doing a recompile, your application will still say "0.92". That's bad...i'll deprecate VERSION in 0.95 and offer a getVersion()-method instead.
You are right about the JAW-problem. I'll fix it in 0.95.

Thanks for the feedback.

Support / Jaw
« on: September 27, 2003, 02:14:58 pm »
You can't. All that's supported is to add texture names behind each triangle definition but that's close to being useless. Support for JAW in jPCT is a relic and unless you are looking for a dead simple format to read a bunch of untextured triangles, it's NOT the format of choice. ASC and/or 3DS should be much better and if size is not an issue, maybe the XML-format is an option too.
Hope this helps.

Edit: I've uploaded all the meshes i have in JAW-format...

Support / problems problems...
« on: September 25, 2003, 10:51:42 pm »
Quote from: "koroljov"
I guess I would better use some sorting algorithm to sort the triangles in the z-order.
Yes. Polygon sorting and drawing front to back is good for software engines (only a limited number of polys to sort, but highly fillrate limited). jPCT is doing this too. In addition, it uses some "tricks" to skip the drawing of hidden spans and to avoid zbuffer-reads in some situations.

Pages: 1 ... 789 790 [791] 792 793 ... 800