Main Menu
Menu

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.

Show posts Menu

Messages - EgonOlsen

#11941
Support / Software reflections, projected shadows, etc.
February 07, 2005, 05:56:05 PM
Anfy3D is much much more low level and basic than jPCT is (there's no much support for anything else then pure polygon pushing). The version i have here shows no traces of support for shadows or mirrors (or at least i'm unable to find them), so i assume that they have "hacked" the engine to do it and that it's not a official feature that you just have to enable.
To answer your question: It it possible to add these things to jPCT, but i won't do it ATM. For mirrors, you should be able to do it yourself by rendering into another Framebuffer which you then use as a texture. It will slow down to a crawl in OpenGL, but should be possible in software mode. Shadows are difficult to add to jPCT's current pipeline...i once started working on that but stopped it after two days. It would require a major refractoring to make them work and that won't happen in this iteration of the engine, i'm afraid.

Edit: google for EgonOlsen and anfy3d to find out what i really think about anfy3d... :wink:
#11942
Support / Rendering different cameras
January 31, 2005, 08:13:31 AM
Quote from: "Melssj5"Should I use a World for every applet instead from one static World on an unique class to handle all the objects????
Not necessarely...that would mean that you have to use multiple instances of your objects too, because an Object3D can only belong to one instance of World. But what you can't do, is render one World with multiple Cameras at a time. A World contains for example the VisList, which will be modified in the rendering. If you render one World in multiple threads, the results will be..whatever...even worse: If you switch to OpenGL one day (and away from an applet), your application will simply crash, because only one thread has the right context for rendering in hardware. So i suggest to do the rendering in one thread and one after the other. If that's not an option and you can for sure say that you'll never use OpenGL in your application, you may extend World and add a kind of locking, so that only one thread can do the rendering at a time and all others have to wait for it to finish.
#11943
Support / Applet example 0.96
January 30, 2005, 04:14:33 PM
Forget about the timer-thread if there should be such thing in the code and replace it with a none-threaded timer approach like the newer examples (fps, car) are doing it.
#11944
Support / Rendering different cameras
January 30, 2005, 02:35:56 AM
I don't understand your problem. It's possible to assign a different Camera to a World to render the world from different views. Why doesn't that work for you? I can't see a difference between doing a setCameraTo(camera1)-render()-setCameraTo(camera2)-render and a render(camera1)-render(camera2)...  :?:

Edit: Or are you trying to render the same instance of World using different cams at exactly the same time using different threads? If that's the case...well, that won't work anyway. You have to make sure that the renders take place in a defined order one after the other.
#11945
Projects / Re: jar compression
January 29, 2005, 02:56:14 AM
Quote from: "rolz"Helge,

I want to obfuscate applet classes for size reduction.
Could i do same with jpct libraries ?

(170 kb technopolies.jar + 150 kb jpct.jar = 181kb technopolies.jar)
The license permits it. So if it works...no problem. However, i would double check on all VMs...sometimes, obfuscated code won't run on one VM or the other.
#11946
Support / Java and OpenGL
January 26, 2005, 07:12:47 PM
Quote from: "DazedDude"P.S Sorry about the non-relativity..Im new to programming  :oops:
No problem... :wink: If you are new to programming, i honestly wouldn't try to start with OpenGL or 3D graphics in general. Try to code something more simple first. If that's not an option, you may consider to use a 3D engine that does the low level work for you. jPCT is such an engine, just give it a try.
#11947
News / LWJGL 0.95 released
January 26, 2005, 06:11:19 PM
jPCT will work with it without any changes. Grab it here: http://www.lwjgl.org
#11948
Support / Java and OpenGL
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?
#11949
Support / Engine Limitations?
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.
#11950
Support / Engine Limitations?
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.
#11951
Support / Engine Limitations?
January 18, 2005, 11:36:54 PM
Try:
 
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.
#11952
Support / Engine Limitations?
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.
#11953
Support / Engine Limitations?
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?
#11954
Support / Engine Limitations?
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 objects
Yes, 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!
#11955
Support / Engine Limitations?
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.