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 ... 789 790 [791] 792 793 ... 798
11851
Support / How does jPCT handle lighting in OGL?
« on: September 05, 2003, 05:36:49 pm »
Quote from: "erikd"

You mentioned that although in theory the number of lightsources is unlimited, one will experience slow downs with large numbers of lights. I suppose this is to be expected, but is there some occlusion/visibility culling regarding lighting to help here? Or maybe I'll have to implement that myself?
Per default, jPCT will take every active lightsource in a scene into account even if it only adds 0.0000000000001 of intensity. However, you can configure the engine, so that it discards lightsources that are too far away from a polygon (0.93 will improve the performance of this discarding a little bit). If you decide to use jPCT, we'll see what happens and if some more improvements are necessary in this area.  Anyway, i think it's quite fast the way it is now.

I already thought about adding multitexturing in one way or another but the OpenGL-only-way doesn't please me and adding it to the software renderer is possible (and not even that hard) but it would require to split the software renderer again into a multitexturing and a singletexturing one, because otherwise the performance of singletextured polygons will drop significantly too. That would make three of them at least... :?
Maybe i'll add it anyway one day or another, because i did that with most of the stuff i was undecided about (like OpenGL-support, the 3DS-loader, animations, texture-tiling...all things that weren't that much fun to do and because i'm lazy, i avoided adding them for some time but finally they made it into jPCT... :wink: ).
However, don't count on it to happen within the next few months...one can only do so much and there are still other things to do (like working on lighting performance... :wink: )

11852
Support / How does jPCT handle lighting in OGL?
« on: September 04, 2003, 07:46:35 pm »
I've seen Mazer before...as well as the zBuffer-flaws the lighting implementation causes... :wink:

To answer your question: jPCT can't to lightmaps, because it can't do multitexturing. This limitation comes from the fact that it's not hardware only but offers a software renderer too. Multitexturing in software is so expensive, that i decided against it and because the feature-set of both renderers should be as equal as possible, there is not support for it at all.
However, it does have its own T&L pipeline and offers a lighting similar to the native OpenGL lighting (i.e. vertex lighting). It supports ambient, specular (in two slightly different implementations) and diffuse lighting with an unlimited amount of lightsources (in theory...in practice, performance starts to drop when you are overusing light).

I guess you've already seen the "viewer"-test-app i posted on javagaming.org. What you see there is all vertex-lighting using some more or less randomly placed lightsources...and i think it looks quite well for vertex-lighting, so maybe this is still an option for your game.

BTW.: The software renderer supports overbright lighting, which increases the possibilities of vertex-lighting very much (i.e. the maximum light intensity per channel is not 1 but 32 in this case). Sadly, no current consumer hardware can do this, so the OpenGL renderer can't make use of it. The 3dfx Rampage would have supported it, if 3dfx would have just survived... :cry:

11853
News / Version 0.92 has been released!
« on: August 28, 2003, 05:47:20 pm »
This is major update compared to the previous ones. Most important: it adds a new restriction...the height of textures used by the software renderer has to be a power of 2 now. This allows the software renderer to support texture tiling (finally).
However, a lot of other things have been done, so have a look at the changes-document here: http://www.jpct.net/changes.html

Have fun!

11854
Support / Orbiting camera
« on: August 27, 2003, 05:29:07 pm »
Fixed it...try the updated version using the same link as above. I was mixing up the coordinates in the method, so the results were totally wrong *most* of the time, but somehow not in my test-case...
Anyway, it should work now. I got it working like this:

Code: [Select]

       cube=Primitives.getCube(20);
       cube.setEnvmapped(Object3D.ENVMAP_ENABLED);
       theWorld.addObject(cube);
       cube.build();

       dummy=Object3D.createDummyObj();
       dummy.setCenter(new SimpleVector(0,-40,-100));
       dummy.setRotationPivot(new SimpleVector(0,0,0));


The thing is, that it works this way, but without any other objects in the scene, you won't notice it (except for the fact that the lighting will change).
Anyway, what i basically did was to offset the center of the dummy so that it starts at the point where the camera should be placed in the beginning. You have to make sure, that the RotationPivots of the dummy and the player are describing the same position in WORLDSPACE after doing the transformation (despite the rotation pivot never actually get transformed...). This can be tricky if they differ in OBJECTSPACE...which they don't in this example (they are both placed at the origin). However, maybe drawing this on a piece of paper helps...at least it helped me. There may be other options to get the same effect, but this should work. Then again, i haven't stressed this method very much, so i'm not sure which fancy tricks it will allow for and which not.
I hope it was somehow understandable what i tried to explain...

11855
Support / Orbiting camera
« on: August 27, 2003, 02:23:11 pm »
First, you can't do that:

Code: [Select]
cameraHolder.setRotationPivot(player.getTransformedCenter());

because you are mixing worldspace and object-space coordinates here, which isn't what you want.
Second, it seems to be my fault...the getTransformedCenter() seems to be fishy. I'm at work, so i could only do some small tests and don't have the source available, but the returned center seems to be a screwed up variant of the actual center. I really wonder why it worked in my short test yesterday... :?:
I got the thing you want working even with the buggy method, but i had to swap coordinates in the SimpleVector and rotate the dummy object around x instead of y....strange...
I'll have a look at the problem, but i'm not sure if i manage to do so today.

11856
News / LWJGL 0.7 is out!
« on: August 26, 2003, 07:52:52 pm »
Get it here: http://www.lwjgl.org/

Anyway, jPCT won't support it until 0.93 or 0.94. I'll wait some days before starting to port jPCT to 0.7, because quite a lot has changed and i want to see how things go first (well, that and i'm lazy... :D )

11857
Support / Orbiting camera
« on: August 26, 2003, 07:33:05 pm »
The beta of the new version available for download here:

EDIT: Removed the link. This version is now official.

The docs and the manual are still in need of some work and that's why this is not an "official" release, but this way you can already test the features you requested. This version is a major update, because some internals have changed and some obsolete stuff from Config has been removed. So in case of problems, please let me know.
Here's a list of the changes until now:

0.92 - Extended matrix-locking to cover the camera too (if locking is used). Worked on Matrix and SimpleVector to increase performance of some methods slightly. Removed unused transparency constants from Object3D. Added support for tiled textures (i.e. texture coordinates below zero and larger than 1) for the SoftGL-renderer. This requires that even the textures used for software-rendering only have to have a height of a power of 2 (jPCT will convert non-power-of-2-textures). Added some methods to SimpleVector, Camera and World to support first-person-shooter-like navigation better. Fixed a bug in the OcTree that caused collisions detection to fail in multi-threaded applications in some rare cases. Fixed a bug in the ray/polygon-collision detection in combination with octrees. Added an algorithm to automatically speed-up collision detection. Modified z-Sorting to ensure a defined sorting order (per frame) even for polygons with equal depth. Removed some unused or now useless configuration variables from Config (public and non-public ones). Reworked both software-renderers to be more pixel-perfect. Removed artifacts from the OptiZ-algorithm. It should work flawless in every situation now. Added the possibility to retrieve an object's center in worldspace.

Oh, and thanx for trying to call calcCenter() on a dummy-object... :lol:  It was bugged because it caused a division by zero in this case. Why the VM thinks that setting it to NaN instead is a better idea than throwing the exception, is still beyond my understanding. But it sometimes does this and after it, floating point code slows down to a crawl... :?

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

11859
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))
and
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:

11860
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) {
      col=texels[((((t1&texClampU)>>18)+(((t2&texClampV)>>18)<<shift)))];

      r=(((col>>16))*(srI>>10))>>16;
      g=(((col>>8)&255)*(sgI>>10))>>16;
      b=((col&255)*(sbI>>10))>>16;

      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)); }
   
      pixels[tx]=b|(g<<8)|(r<<16);
      zbuffer[tx]=iz;
   }

   t1+=dus;
   t2+=dvs;

   srI+=delr;
   sgI+=delg;
   sbI+=delb;

   iz+=delz;
}


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.

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

11862
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: http://www.jpct.net/manual2/index.html)...be 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: http://www.jpct.net/download/world.xml
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!

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

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

11865
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();
mat.setIdentity();
obj.setRotationMatrix(mat);


or

Code: [Select]

Matrix mat=new Matrix();
obj.setRotationMatrix(mat);


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.

Pages: 1 ... 789 790 [791] 792 793 ... 798