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 ... 786 787 [788] 789 790 ... 798
News / Version 0.95 has been released!
« on: November 10, 2003, 06:21:38 pm »
Changes/fixes are documented here:

Have fun!

Bugs / ArrayIndexOutOfBoundsException when loading 3ds in FPS demo
« on: November 09, 2003, 06:12:42 pm »
I don't have 3DS at all. All i have are converters from and to 3DS. Seems like the error happens when merging the objects from the 3DS-file into a large one. It would be very helpfull if you could send me such a file of yours, so i can reproduce the problem better.

Edit: Fixed in 0.95

Support / Level file format - final ?
« on: November 03, 2003, 05:44:20 pm »
I'm not quite sure what you mean with "level-format" can basically use any supported format (well, except MD2) for storing your level. The demos are using the 3DS-format. It's quite small (at least compared to the ASCII-based formats) and a lot of tools are available for conversion from and to 3DS.
The XML-format was an attempt to create something that's easy to read/write, extendable and that supports portals. You may use it, but you have to do the conversion into jPCT's XML-format yourself.

About the final-thing: There are two reasons for this. Older VMs like it performance wise and there's not much encapsulation used within jPCT, so it would be quite hard to extend Texture (for example) without knowing something about the inner workings. I did this to keep the API small and fast...the price you pay for this is, that it's not easy for others to extend it. I can remove the final and see how it works out performance wise, but i doubt that you'll be very happy with it. What exactly do you have in mind? Using an int[](byte[])-array from an instance of your Image-object as a texture instead of loading it from somewhere else?

Support / texture
« on: November 03, 2003, 05:30:35 pm »
What does the texture do instead? Maybe you are using environment mapping for the sphere. What you should do is to either project a texture onto the sphere using Object3D.calcTextureWrapSpherical() or Object3D.calcTextureWrap() or use the sphere object i'm using for the demo. It's in ASC-format and can be found here: The suffix is ask instead of asc because older Netscape-browsers are having some problem with applets loading asc-named files.
Hope this helps.

Feedback / The future of jPCT
« on: October 30, 2003, 12:03:19 am »
Quote from: "erikd"
Are you limiting the hw renderer's featureset because the current jPCT is designed as a software renderer or is it a design goal that both hw and sw renderers have identical features?
A little bit of both... :wink: jPCT's basic idea was to provide fast software rendering. I never even thought about hardware support before LWJGL surfaced and even then, it took me some time (and some requests by others...) to convince myself to try it. I wanted to stay compatible with 1.1. and be able to run jPCT in applets. Applets are quite pissy about imported classes that aren't there even if you don't use them, so you have to hide Java2 class-usage from 1.1 by using the plugin-approach the FrameBuffer and the IRenderer are offering. This limits the knowledge about LJWGL/OpenGL to the GLRenderer and it requires some "tricks" to get things working. Blitting and RGBScaling are examples of this. So even if it's possible to add hardware features regardless of the software renderer, the current design makes it difficult to do that in a convenient way sometimes. On the other hand, i really don't want to change the API everytime and force people to refactor their applications every month. That's something i really hate to do myself, so i'm trying to avoid it...
jPCT's hardware support is quite separated from the rest of the engine. If it weren't, i would have to maintain two completely different rendering pipelines making the code/API a mess and the size would grow. That's the reason why jPCT isn't a polygon pusher...hardware T&L is used somehow, but not to an extent. HW and SW are basically using the same pipeline until drawing of the actual polygons starts.
And finally, i want sw and hw to behave as equal as possible. That's because i think that it's usefull for pushing 3D into the Java-world, like it was usefull for Unreal to offer a software mode. Aside from and similar communities, 3D in Java is not taking place IMO, so i think it's important to make is accessible for as much people as possible to show that it could be done and to show them how they may benefit from using it. When this is achieved, you can think about adding all the fancy features...but maybe in another engine...(jPCT2.0+  :wink: )

Support / landscape viewer applet
« on: October 29, 2003, 11:17:12 pm »
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 (things like Loader or Primitives for example don' 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.

Support / Octree question
« on: October 25, 2003, 04:22:04 pm »
You may ignore the problem...the culling won't be performed using the octree nodes then but the objects' bounding boxes. If we aren't talking about zillions of objects here, this should be fast enough...
If not, you may have a look at Object3D.translateMesh(). This does a physical translation of the object in object space, so you may setup the translation for each object, call translateMesh() for each and merge them afterwards. This way, you should get one large object with the cubes at the correct positions.

Hope this helps.

Feedback / The future of jPCT
« on: October 25, 2003, 11:54:00 am »
You definitely have a point here and i'm thinking about the future of jPCT too. I'm a bit undecided about all that...on the one hand, i like the fact that jPCT is small, simple to use and runs almost everywhere where Java runs. On the other hand, i would like to add more features for hardware that i can't do without leaving software behind...and sometimes it's even the other way 'round. Then again, do we really need another Java3D clone like Xith3D and OpenMind? jPCT is a bit "different" and i really want it to be that way.
Currently, i think that this may happen in the future: jPCT will basically continue as it is and i'll start a jPCT2.0 project in parallel with a redesigned API (something i'm avoiding at all costs with jPCT) and a better support for the features you mentioned. Will this version still have software rendering? Maybe, but i won't limit the hardware renderer's feature set anymore because of it.
Now that i'm typing this, i'm asking myself again: "Do we need another 3D API that works that way?"
However, all this won't happen tomorrow or within the next months, but i'm quite confident that i'll start such thing when jPCT in its current shape is totally maxed out.

Support / landscape viewer applet
« on: October 25, 2003, 11:40:56 am »
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.

Support / Re: serializable
« on: October 23, 2003, 06:24:48 pm »
Quote from: "danmeany"
if World and it's all it's potential children are, 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?

Support / landscape viewer applet
« on: October 22, 2003, 08:59:58 am »
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.

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.

Pages: 1 ... 786 787 [788] 789 790 ... 798