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 ... 785 786 [787] 788 789 ... 794
Support / Orbiting camera
« on: August 26, 2003, 06:47:51 am »
I see...the problem is, that getCenter() returns you the center in object-space while you want to get the center transformed into world-space. It should be possible to emulate this behaviour somehow, but i think it's better to add a new method like getTransformedCenter() to Object3D and maybe a convenience method to do the camera placement using this value to Camera too.
I'll add this to the next release, which should be out in the next 48h (i'll try to get things sorted today) and YOU will have to play beta-tester for this method  :lol:
I'll let you know...
BTW.: I'll document this behaviour of getCenter() in the docs, because it seems to be misleading the way it is documented now.

Support / source
« on: August 19, 2003, 11:51:42 pm »
Quote from: "Koroljov"
It is very interesting. It is much faster than using
u =  (i*(Vz*Oy-Vy*Oz) + j*(Vx*Oz-Vz*Ox)+(Vy*Ox-Vx*Oy))/(i*(Vy*Uz-Vz*Uy)+j*(Vz*Ux-Vx*Uz) + (Vx*Uy-Vy*Ux))
v = ( i*(Uy*Oz-Uz*Oy) + j*(Uz*Ox-Ux*Oz) + (Ux*Oy-Uy*Ox))/( i*(Vy*Uz-Vz*Uy) + j*(Vz*Ux-Vx*Uz) + (Vx*Uy-Vy*Ux))
Obviously... :wink:

Support / source
« on: August 17, 2003, 12:55:43 pm »
Quote from: "koroljov"
Can't you tell some names of the used algorithms so I can seek them on the internet? How can it work so quick in full screen? How many divisions are there in the inner loop of the application? How is it clipped? How can you make a color lighter or darker? Do you really have to get the r g b -values, edit them and put them in 1 int again with lots of << and >> operators?
Sorry for the late reply, but i was on a trip to sweden for two weeks. The inner loop for a point-sampled pixel looks like this

Code: [Select]
for (int tx=x+yPos; tx<=end; tx++) {

   if (zbuffer[tx]>iz) {


      if ((r&0xffffff00)!=0) { r=(255>>(byte) (r>>28&8)); }
      if ((g&0xffffff00)!=0) { g=(255>>(byte) (g>>28&8)); }
      if ((b&0xffffff00)!=0) { b=(255>>(byte) (b>>28&8)); }




In the inner loop, the subspans are linear interpolated, so no division is needed here. In the loop that does the subdivision, no division is needed too because it has all been replaced by multiplying with 1/(whatever).
I don't know where to look on the net for a better description, because it's simply the way i'm doing these things for ages now.
Please note that this is the inner loop of the SoftGL-Renderer which requires some multiplications and supports texture-wrapping from version 0.92 (to be released...) on, so it's a bit slower than the Legacy-Renderer, but not much.

Support / Disable Lighting
« on: July 16, 2003, 10:00:51 pm »
The new version is out and has this option included. Have a look and see, if this is what you need...

News / Version 0.91 has been released!
« on: July 16, 2003, 09:22:07 pm »
0.91 is out! It features an enhanced documentation (i started to write a kind of "manual" which can be found online too: kind, it's still in its infancy.), a new method to disable lightsources for an object and a refactored Loader-class (i hope it still works). The Loader supports loading a XML based format now (the format itself is subject to change a little bit in the future though).
A DTD for the XML can be found in the docs, an example XML file can be found here:
For this, a small XML-Parser has been added to the package and because it has absolutely nothing to do with jPCT itself, it has been placed in a new "util"-package.
Have fun!

Support / Disable Lighting
« on: July 08, 2003, 07:32:09 pm »
No. I never thought of this... :oops: But i'll add it. Would it be satisfying to disable influence of the lightsources on an object and to leave ambient light and additional color active in the calculation? The problem with disabling ambient lighting is, that it doesn't work on a per-object base and that it requires a different treatment if the renderer is in OpenGL mode or not.
I've already added this option to 0.91 and you'll get it with the next release. The question remains, if this is enough or if it's needed for your application to disable ambient on a per-object base too. In that case, i'll have to think about the topic once again...please let me know.

Support / Rotation Point
« on: July 08, 2003, 03:50:03 pm »

Support / Reset Transform
« on: July 06, 2003, 02:51:14 pm »
You may set the rotation- and translation-matrix to whatever instance of Matrix you wish. To reset them, just do:

Code: [Select]

Object3D obj=....
Matrix mat=obj.getRotationMatrix();


Code: [Select]

Matrix mat=new Matrix();

The later way involves a creation of a new Matrix object, which may be little slower, but depending on what you want to do, more appropriate.
Because getRotationMatrix() returns the reference to the rotation matrix, an obj.getRotationMatrix().setIdentity() should do the trick too, but i simply don't like to rely on such a behaviour because it may (most likely won't, but anyway...) change in the future.
Setting the translation matrix works the same way.

Support / Nonuniform Scaling
« on: July 04, 2003, 12:15:45 am »
No...and yes...jPCT's standard scaling behaviour doesn't allow this. The reason for this is, that jPCT doesn't really use a scaling matrix but a virtual scaling matrix with sx=sy=sz=s. The easiest way to explain this quite strange behaviour is: "historical reasons"... :D
This may not satisfy you and i understand that. But i don't think that i'll break the current implementation to add support for non-uniform scaling.
However, jPCT 0.90 features support for what i've called "VertexController"s. So you may write yourself a VertexController that does the non-uniform scaling for you...should be quite easy to do once you got the concept of the VertexControllers. This is NOT an ideal solution...i know that. Anyway, it's the only way to do it ATM. Maybe i'll think about adding a real non-uniform scaling later if it's really important to you and you can't live with the "Controller-solution".

News / Version 0.90 has been released!
« on: July 01, 2003, 11:20:27 pm »
Some minor things like an improved collision detection performance for ray-polygon collisions and some cleanup work. A major addition is the possibility to now build yourself a VertexController to modify vertices of already constructed objects. This is something that wasn't possible in jPCT before. The usage of the VertexController may not be very intuitive, but i'm planning to add a demo of that. For now, look at this source code to see a sample implementation:

Code: [Select]
public class DemoVertexController extends GenericVertexController {

     int count;

     DemoVertexController() {

     public void apply() {
       SimpleVector[] srcMesh=this.getSourceMesh();
       SimpleVector[] dstMesh=this.getDestinationMesh();

       int size=this.getMeshSize();

       for (int i=0; i<size; i++) {
         float z=srcMesh[i].z;
         float x=0.25f*(srcMesh[i].x+count);
         float sin=(float) Math.sin(x);


Yeah right! The VertexController stuff may sound more complicated than it really is when it comes to implementing one (note that this implementation skips updating the vertex normals, which is not quite correct).

Use your new controller like this:

Code: [Select]

      IVertexController demoControl=new DemoVertexController();
      Object3D obj=Primitives.getPlane(20,5);
      obj.getMesh().setVertexController(demoControl, IVertexController.PRESERVE_SOURCE_MESH);

Note that the call to build() has to be placed before the getMesh() to make sure that the normals are calculated. This isn't mentioned in the current docs, so i'm mentioning it here.

The result will be a plane whose vertices are being modified by the VertexController in realtime. Can't show it in motion ATM, so here's a quick and dirty picture of it (not that it's very impressive but it may help to understand what a VertexController is supposed to do):

Support / skeleton control
« on: June 30, 2003, 01:23:22 am »
I guess you are talking about skeletal animation like Half-Life uses it (just to name one)? I'm not too sure that this will make its way into jPCT in the near future...I know that it would be a nice to have feature though. Please don't count on it...but then again, i once said the same about OpenGL and MD2 support.. :) I know that this isn't a very satisfying answer, but it's all i can say about this topic ATM.
I don't quite understand the second question...why do you want to call LWJGL directly?
To explain how jPCT makes use of LWJGL: The one and only class that knows something about LWJGL is the GLRenderer (as an implementation of the IRenderer-interface). No other class know a single bit about LWJGL (or any other renderer implementation).

Projects / Re: Semester's Work done!
« on: June 27, 2003, 12:48:14 am »
Quote from: "PrimordialSoup"
I may have an applet demonstration soon.
What happened to that idea? I would be very interested in your results.

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'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.

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?

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 if you decide to write such thing, i would be greatly interested in your solution.

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