11926
News / LWJGL 0.95 released
« on: January 26, 2005, 06:11:19 pm »
jPCT will work with it without any changes. Grab it here: http://www.lwjgl.org
News:
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.
11927
Support / Java and OpenGL
« on: January 26, 2005, 06:05:37 pm »
Albeit this is a jPCT forum and your question isn't related to jPCT, i'll try to answer it.
First, don't use GL4Java...it's simply outdated. Use either JOGL (if you want SWING/AWT support) or LWJGL (if you want ease of use and flexiblity).
I've never seen such thing that you are asking for (which doesn't mean that it doesn't exist). Wouldn't it be wiser to write the code to CREATE the objects yourself into a simple data structure and render that? What kind of shapes are you talking about?
First, don't use GL4Java...it's simply outdated. Use either JOGL (if you want SWING/AWT support) or LWJGL (if you want ease of use and flexiblity).
I've never seen such thing that you are asking for (which doesn't mean that it doesn't exist). Wouldn't it be wiser to write the code to CREATE the objects yourself into a simple data structure and render that? What kind of shapes are you talking about?
11928
Support / Engine Limitations?
« on: January 20, 2005, 12:30:25 am »
jPCT doesn't create a window for you in software mode, but it has to in hardware mode. Simply because the used OpenGL binding can render into its own window only. The second window must be opened by your application. Just don't do that and use the lwjgl window instead. You can't use mouse or keylisteners on this one though. You have to use the means that lwjgl provides for keyboard and mouse or use the KeyMapper from jpct.util.
11929
Support / Engine Limitations?
« on: January 19, 2005, 12:37:09 am »
You have to set both, the jar and the dll (assuming that you are using Windows). The dll is set by setting the library.path (similar to the -Xmx stuff before) to the directory where the dll is stored. Have a look at the examples' batchfiles that come with jPCT to see how to set the library.path correctly.
11930
Support / Engine Limitations?
« on: January 18, 2005, 11:36:54 pm »
Try:
But be sure that your current FrameBuffer size is supported by your hardware. That not important in software, but it is in OpenGL.
Code: [Select]
buffer.enableRenderer(IRenderer.RENDERER_OPENGL);
buffer.disableRenderer(IRenderer.RENDERER_SOFTWARE);But be sure that your current FrameBuffer size is supported by your hardware. That not important in software, but it is in OpenGL.
11931
Support / Engine Limitations?
« on: January 18, 2005, 12:50:20 am »
oookkkk...in that case, it's getting more complex. Recreating the object for every added/removed tile will most likely (as you've noticed) be too slow. I can think of two options: Split the map into strips (i.e. for a 512*512 map, that would be 512 strips and each one consists of 1024 triangles) and rebuild those or, if all you want to do is to modify the texture, use one large Object3D and use the PolygonManager it set the textures. It could be bit tricky to figure out which PolygonIDs refers to which tile, but it shouldn't be too difficult either. If you want to modify terrain height and such things, have a look at the GenericVertexController and the IVertexController interface. With them, it's possible to manipulate the geometry of a mesh after building it.
11932
Support / Engine Limitations?
« on: January 18, 2005, 12:19:45 am »
It's not clear to me what you are trying to do. You are creating a tile base map, right? When and why are you rebuilding your map? What exactly do you mean by "rebuilding"? Calling rebuild() on the Object3d that is the map or recreating the map itself?
11933
Support / Engine Limitations?
« on: January 17, 2005, 11:46:39 pm »Quote from: "bgilb"
right now for each texture its its own Object, would it be bad to make each tile its own object? sounds risky since that would be ( for the biggest map ) 65,000 objectsYes, that's a very bad idea. Performance will go down to the cellar and memory usage up through the roof. Just don't do it!
11934
Support / Engine Limitations?
« on: January 17, 2005, 11:45:05 pm »
Maybe 1024m is a bit too much.... :?: It may take some time to create a 512*512 map. How much depends on what you are doing exactly. If you want, you can post some code of your map's creation and/or the texture modification code to see what happens there.
11935
Support / Engine Limitations?
« on: January 17, 2005, 11:29:51 pm »
How are you starting your application? From inside an IDE? Which one? In JBuilder for example, you can add additional command line parameters to the project. You just have to add that -Xmx128m there and you are done. In Eclipse or Netbeans, it should be similar.
11936
Support / Engine Limitations?
« on: January 17, 2005, 11:14:37 pm »
That's not an engine limitation, it's caused by the fact that the JVM defaults to 64mb max. To change this, start your application with the additional command line switch "-Xmx128m" or "-Xmx256m" or whatever you prefer. The VM won't grab all that memory from the beginning, so don't worry.
11937
Support / Engine Limitations?
« on: January 17, 2005, 10:11:17 pm »
Which limit? You are giving the maximum number of triangles for an Object3D in the constructor, that's true. But what prevents you from creating an Object3D with let's say 100000 triangles? Or am i not understanding your question correctly?
11938
Feedback / The future of jPCT
« on: January 17, 2005, 06:53:18 pm »
If you find jPCT easier than xith3d or jME, then the idea worked. jPCT's goals were ease of use and a small size. That's the reason why its whole functionality is build around the two monoliths World and Object3D. This may also have some drawbacks and it doesn't look very "stylish" but it's easier to understand and its clear where to search for specific methods IMHO.
It also tries to hide the difficult stuff from the user as long as he doesn't need it. That's something where the other approaches fail IMO. It's ridiculous to follow a discussion in the xith-forums if xith should come with a normal generator or not, or why the collision system is broken and won't be fixed and ODEJava is much better anyway...there's no question that there should be a normal generator in a 3D engine (in fact, it was one of the first things that i've added to jPCT) and it's mandatory to have a working collision system. With jPCT, you don't even have to know that normals exist and what they are good for. The same for collisions: It's one line of code to check for a collision. If you want more info about the collision, implement a CollisionListener and you are done. But you don't have to...
I agree, that the current website has its problems to promote the project. On your first visit, it looks like just another applet demo. The frontpage doesn't tell you anything about what this really is all about. That's partly due to the fact that it wasn't much more than a just another applet demo when i designed the page. I think i could do much better now, but it's a question of motivation. I think i have to do it sooner or later though.
However, when you search for "java 3d engine" on google, jPCT comes second with no trace of xith3d and jME...but obviously, this isn't enough to make people think that it's actually a mature and stable product.
It also tries to hide the difficult stuff from the user as long as he doesn't need it. That's something where the other approaches fail IMO. It's ridiculous to follow a discussion in the xith-forums if xith should come with a normal generator or not, or why the collision system is broken and won't be fixed and ODEJava is much better anyway...there's no question that there should be a normal generator in a 3D engine (in fact, it was one of the first things that i've added to jPCT) and it's mandatory to have a working collision system. With jPCT, you don't even have to know that normals exist and what they are good for. The same for collisions: It's one line of code to check for a collision. If you want more info about the collision, implement a CollisionListener and you are done. But you don't have to...
I agree, that the current website has its problems to promote the project. On your first visit, it looks like just another applet demo. The frontpage doesn't tell you anything about what this really is all about. That's partly due to the fact that it wasn't much more than a just another applet demo when i designed the page. I think i could do much better now, but it's a question of motivation. I think i have to do it sooner or later though.
However, when you search for "java 3d engine" on google, jPCT comes second with no trace of xith3d and jME...but obviously, this isn't enough to make people think that it's actually a mature and stable product.
11939
Support / Texture not showing up.
« on: January 15, 2005, 02:32:19 pm »
You mean a method that takes an array of vertices and creates the triangles from that like you do in your code "by hand"? No, there is no such thing ATM. I may add it, if it's really needed.
Alpha or transparency is only supported on a per Object3D base. That's mainly a tribut to the software rendering.
The order of the vertices that form a triangle counts, because it's used for backface culling. If your order is wrong, the triangle will de visible from the other side.
About the tiled terrain...i would say that it doesn't matter. jPCT will take care of the vertex sharing itself, you don't have to worry about it.
Alpha or transparency is only supported on a per Object3D base. That's mainly a tribut to the software rendering.
The order of the vertices that form a triangle counts, because it's used for backface culling. If your order is wrong, the triangle will de visible from the other side.
About the tiled terrain...i would say that it doesn't matter. jPCT will take care of the vertex sharing itself, you don't have to worry about it.
11940
Projects / Technopolies
« on: January 11, 2005, 08:51:42 pm »
Amazing...this really is the most advanced applet game that i've ever seen...