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 ... 794
11806
Support / how to asemble several objects as one
« on: June 13, 2003, 05:17:16 pm »
Quote from: "urd"
i guess i got it..what dummy mean  is a "unseen skeleton".it can assemble objects with an "unseen skeleton"is my thought correct? ^^||
Hmmm, i wouldn't call it a skeleton because that sounds like it has a dimension somehow...it's just an unseen "point" in space that can do transformations. Like an infinitely small object. A kind of connector between otherwise unrelated objects. The example of the planet above shows, that such a functionality is needed (or at least very helpfull) in some cases.

11807
Support / Re: how to asemble several objects as one
« on: June 12, 2003, 05:48:02 pm »
Quote from: "Anonymous"
is the"dummy" means a ..human body model?
No, it's not a crash test dummy or something... :D It's called "dummy", because it's not a real (i.e. complete) Object3D. It has no polygons, no vertices and no properties (well, it has them but there are ignored). It doesn't have to be added to an instance of World either. All it really is, is a kind of container for a transformation matrix. This is due to the fact that jPCT is not a pure scene-graph based API but borrows some elements from the scene-graph concept.
Anyway, what is it good for? Ok, imagine a planet spinning around the sun and a moon spinning around the planet. The planet itself is spinning around its vertical axis too. So the basic transformation the planet does is the rotation around its own center while the moon should rotate around the planet. Two problems arise here: The moon should follow the planet if it's moving (i.e. spinning around the sun, which i'll cover later) but it can't be a child of it, because it must not inherit the planet's rotation around its center. The other problem is, that the planet is spinning around itself, but not around the sun. A dummy object is a convienient way to solve this. You create a dummy object and place it into the center of the planet. This dummy object has its rotation pivot in the center of the sun. This way, the dummy rotates around the sun, which is what the planet should do to. So you attach the planet as a child of the dummy. The same goes for the moon: Set the rotation pivot to the center of the planet and attach it as a child to the dummy. This way, both objects will follow the dummy around the sun while performing their own, independent rotations too.
Have a look at the downloadable jPCT-demo. There is a room with a planet and a moon rotating around a pillar that illustrate exactly (almost...) this effect.
Somewhat clearer now?

11808
Support / keyboard control
« on: June 11, 2003, 06:12:15 pm »
First, i suggest to add an "e.printStackTrace()" in the catch-block to see what kind of exception actually occurs.
IIRC, LWJGL requires that the GLWindow has been constructed before creating the keyboard, because the keyboard needs a "component" to focus to. Try creating the keyboard after enabling the OpenGL-renderer in jPCT. Otherwise, it won't work.
Your second approach should work when using the software renderer, but not when using the OpenGL renderer, because the LWJGL window isn't a component in the thinking of Java. Therefor, it's not possible to bind a keylistener (or mouselistener or whatever) to it.
This is a kind of dilemma: When rendering into a standard Java component (using the software renderer), you may use the keylistener and you can't use the LWJGL keyboard polling, while you have to use it when using the OpenGL renderer (and can't use the listener in this case). The best way IMHO would be to encapsulate the keyboard related stuff in a class that supports both ways somehow and uses what's appropriate in the given situation. While i wouldn't include this in jPCT directly, it would be a nice addon for it...so if you decide to write such thing, i would be greatly interested in your solution.

11809
Support / Re: how to asemble several objects as one
« on: June 11, 2003, 06:03:23 pm »
Quote
i got it.so if i have the need to rotate and transform my arm fixed to my body at the same time,i need to asemble object by hand,and use addchild/add parent to make they have hierachie relation.then i use transform to the main body, other arm/leg/head....will  transform as the same.is it correct?^^||.sorry it seem i am somewhat suck in 3d progaming/_\

Yes. A child object inherits the transformations (rotation/translation) of its parent. There can be more than one parent, but i would try to organize my scene in a way that i get away with max. one parent per object. I don't even know anymore, how multiple parents are implemented exactly... :D
Example: You make the arm a child of the body and the hand a child of the arm. This way, hand and arm are transformed if the the body is and the hand inherits the transformations of the arm in addition. Sometimes, it's usefull to use "virtual" objects to build up your hierachie. You can achieve this by using "dummy"-object (see: Object3D.createDummyObj()).
Hope this helps.

11810
News / Forum updated to 2.0.4
« on: June 10, 2003, 11:47:17 pm »
I hope everything went well...

11811
Support / Re: how to asemble several objects as one
« on: June 10, 2003, 09:20:17 pm »
Quote from: "urd"
hello everyone,i am a fresh guy programming 3d.^^
this engine is very cool:lol: ..can't imagine that before,making 3d game is not hard work.
i have a question that if i load objects from a 3ds file including head,leg,body,arm....which each is a object
how do  i assemble and fix the arm to the "correct position" ?can i make it is jpct?
I'm not quite sure if i'm understanding your problem correctly. Do the objects reside in different 3ds-files or are they all in one? The the later case, the positions of the parts should be fine, because jPCT will import them as they are placed in the orginal model. In the former case, you would need to do the positioning "by hand" by finding the right position for every part.
If this wasn't the question, then maybe you are referring to a possibility to group seperate objects into a single entity. What you can't do (not yet) in jPCT is merging objects into a new one. What you can do, is building up a hierarchie between them by using the addChild() and/or addParent()-methods from Object3D. With them, you may add all body-parts to the chest (or to whatever is appropiate in your case...maybe a dummy object...whatever...) and then the child-objects will inherit all transformations of the parent object.
Does this answer your question somehow?

11812
Feedback / Still Another Suggestion...
« on: June 02, 2003, 10:30:55 pm »
Quote from: "Ambience"
Not that it would really matter, but i can't find that setTransparentColor() method you mentioned. Did you forget to add it or am i blind?
Yes, i guess i've missed that one...not a big loss though. Maybe i'll add it to a later version.

11813
Support / Loading bsp or map files
« on: May 19, 2003, 07:02:55 pm »
You are basically correct. The only problem is, that using portals won't be possible that way, because the geometry won't be prepared accordingly. If you intend to use portals, you would have to load the level "by hand". None of the loaders of jPCT support them ATM. Anyway, Octrees are supported on such a level and depending on the level, they could very well be sufficient (or even preferable).
Just give it a try. Oh, and let me know if you find a good converter for this task... :D

11814
Support / Source code of jPCT demo
« on: May 12, 2003, 06:51:12 pm »
Have you downloaded the API (not just the demo)? The API comes with complete(?) javadocs and two small examples to get you started. The sources of the demo are NOT available for two reasons:

1.) They are not up-to-date. The demo is based on 0.79 while the latest release is 0.89.
2.) (the more important reason) The sources of the demo are a real mess. I would have to clean up them very very much to be usefull to someone except myself. The demo is basically my testing application. I don't even have something on my hands that represents the downloadable state of the demo...the current demo-test here on my HD looks everything but nice...it's just for testing new features and other changes.

I'm sorry, but for the reasons mentioned above, i won't give the sources away. But i strongly suggest to have a look at the examples that come with the API.

Hope this helps...

11815
Support / A few questions...
« on: May 07, 2003, 10:34:27 pm »
Quote from: "GP"
Wow, downloaded and going to test it tomorrow...   :D  I am sorry for this hard work I am causing, I hope many will take advantage of these features!
Did it work? Anyway, it's in the new 0.89 release... :D

11816
News / Version 0.89 has been released!
« on: May 07, 2003, 10:17:27 pm »
I've added a way to offset the viewport (for sidebars and similar) and upgraded to LWJGL 0.6. This means, that jPCT 0.89 now works with the new version of LWJGL. It won't work with the older 0.5 anymore. Some changes to video-mode selection were required to reflect the changes in LWJGL in these areas.
The software renderer will of course work without any version of LWJGL (as usual  :wink: ).

11817
News / LWJGL 0.6 is out!
« on: May 07, 2003, 08:45:34 pm »
FYI: A new version of LWJGL (the lib jPCT uses for the OpenGL binding) is out, but jPCT 0.88 won't work with this version. 0.89 will.

If you are interested in LWJGL, grab it here: http://java-game-lib.sourceforge.net/

11818
Support / A few questions...
« on: April 28, 2003, 05:57:52 pm »
Update on the sidebar problem: I've uploaded a pre-release of 0.89 which has an option included to apply an offset to the viewport and it hopefully works in software as well as in OpenGL. There are two new configuration options in Config called viewportOffsetX and viewportOffsetY. The offset is in fact a factor and independent of the resolution...have a look at the docs for futher detail about these settings.
This should also help to reduce the amount of polygons overdrawn by the sidebar anyway, so it should be a little faster too.
The version can (only) be download here: *removed*...the normal distribution contains this option now.
Let me know, if it helps.

Edit: Fixed the link...

11819
Support / A few questions...
« on: April 26, 2003, 04:10:17 pm »
Before the days of the OpenGL renderer, this would have been rather simple. You can access the Image-instance that holds the pixels generated by the software renderer and blit it into whatever and whereever you want. But though it's possible, it's not very convenient. Therefor, i once added an option to jPCT (that isn't available via the API at the moment) that "shifts" the projected 2D coordinates in any direction, because this is, what's actually needed to avoid the problem: If your sidebar is for example 100 pixels, you would like to start the rendering not at x=0 but at x=100. This is no problem with the software renderer, because i have full access to every pixel and can do whatever i want to. However, i didn't find a working way to tell OpenGL not to start rendering at (0,0) but somewhere else. That's why the option to do this is not publicly available.
Manipulating the matrices doesn't help btw, because what you want is basically a 2D operation...just tell the stupid polygon to start at (x+a,y+b) instead of (x,y) on screen (the position in 3D wouldn't change). I just don't know how to achieve this in OpenGL ATM...maybe i'll have a closer look again one day (glViewport comes to mind...but i tried that once and it failed somehow...well, maybe i'll give it a shot again...). For now, i suggest to take it as feature. Maybe you want to make the sidebar removable... :wink:

Edit: About the filtering: Maybe it hurts performance on PowerPC's and their VMs more than it does on Intel...can't wait to see what happens when LWJGL comes out for Mac (byteorder anyone... :roll: ?).

Edit2: I forgot to mention this in the docs of 0.88: The coords the projectCenter...stuff returns are backbuffer coords, i.e. if you are using 1.5 or 2 times oversampling, you have to divide them by 1.5 (or 2) to get the actual coords of the frontbuffer (for blitting and stuff). 0.89's docs will mention this.

11820
Support / A few questions...
« on: April 24, 2003, 10:27:58 pm »
Make sure to use software rendering in MODE_OPENGL to ensure that soft- and hardware will almost look the same. The reason is, that jPCT's default rendering mode is software legacy which uses a different lighting model that OpenGL doesn't support (and that's sad because i think that it, may it be realistic or not, produces better results than the standard lighting OpenGL supports). Have a look at the terrain example's sources to see what i mean. Or, if you are already doing this, ignore my post... :wink:

BTW: Texel filtering shouldn't be much slower than not using it...if it's noticable at all. I've put a lot of affords into optimizing the software renderer may it be with or without filtering.

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