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 ... 780 781 [782] 783 784 ... 796
11716
Support / Randomly Generating Object3D's
« on: January 22, 2004, 01:06:40 am »
Not sure if this will help you much, because the bubbles are managed in a reeeeaaalll simple way, but anyway:
Code: [Select]

for (int i=0; i<NUMBER_OF_BOXES; i++) {
         Object3D box=Primitives.getSphere(4,1);
         box.calcTextureWrapSpherical();
         box.setTexture("wood");
         box.setTransparency(0);
         box.setEnvmapped(Object3D.ENVMAP_ENABLED);
         box.setCollisionMode(Object3D.COLLISION_CHECK_SELF);
         box.setOrigin(new SimpleVector(140,0,-117));
         setBox(box, i);
         box.translate((float)Math.random()*-140, 0, (float) Math.random()*117);
         theWorld.addObject(box);
         boxes[i]=box;
}


And the code for setBox():
Code: [Select]

private void setBox(Object3D box, int i) {
      float x=15f-30f*(float) Math.random();
      float y=20f-40f*(float) Math.random();
      float z=15f-30f*(float) Math.random();
      box.setTranslationMatrix(new Matrix());
      box.translate(new SimpleVector(x, y, z));
      float trXn=1.5f+2f*(float) Math.random();
      float trZn=1.1f+2f*(float) Math.random();
      trX[i]=trXn/2f;
      trZ[i]=trZn/2f;
      lifeTime[i]=0;
      box.rotateX(x);
      box.rotateY(y);
      box.rotateZ(z);
}


The bubbles are stored in the array named boxes (they were boxes in the first version... :wink: ) and their current translation in X and Z direction in trX and trZ. In addition, the lifetime of each bubble is stored in the lifeTime[]-array. But this is ugly code written to serve a single purpose. It would be better to wrap this information into an object (or maybe to extend Object3D, which sadly isn't possible in 0.97 but will be possible in 0.98 because i'll get rid of the useless final-stuff) and manage these objects by a simple Manager-class. If you don't want to write such a wrapper class and go with the array-approach, the Manager is still a good idea because it can hide this fact from the rest of the code.

Hope this helps.

11717
Projects / tokima
« on: January 20, 2004, 10:11:29 pm »
Quote from: "acorn98"
Also, I have a couple of very long fences with a tiny repeating texture which seems to warp into a diagonal line - I think it started happening when I stretched the object to its current length (which is pretty big). Is it a bug, do you think?


Are you talking about this? :



(i applied some "Gamma" to it...)

I'm not sure what that is exactly...could it be that the u/v-coordinates are very high here? Like (1000,1000) / (1000,1001) / (1001,1001) for such a triangle instead of (0,0) / (0,1) / (1,1)? That's the only idea i have ATM, because it can result in an overflow somehow. The renderer uses fixed point math for the coordinates but even 32bits are not enough sometimes. I think the highest value possible should be around (+-)256 or (+-)512...i not quite sure ATM. Could that be a problem here?

11718
Projects / tokima
« on: January 20, 2004, 07:11:13 pm »
Quote from: "acorn98"
There's some bad poly overlap in places, mainly due to my abilities with 3dsMAX - I'm still getting to grips with it. My next effort should be considerably cleaner.
.......by the way - that fps source was fantastic.
Yes...i noticed that there seems to be one (or some) large polygon below the street's actual polygons which "shines through" due to inaccuracies in the zBuffer (caused by the nature of it...nothing i can do about it). That's causing most of the z-fighting problems and it hurts fillrate and the octree. You should try to get rid of it IMHO.
The newer versions of the fps-code are even better... :wink: (No multi-threading issues anymore).
Keep up the good work. I really like the mood of this level.

11719
Projects / tokima
« on: January 20, 2004, 06:46:29 pm »
Looks great and proves that simple vertex-lighting can still produce very nice results. However, i noticed two issues while running around in the level: There's some Z-fighting when polygons overlap. But that's a "problem" with the model, not with the code. It's not that bad anyway.
I assume it's somehow based on the fps-demo? If so, on which version? Older versions did the actual movement in the timer-thread and with the upgrade to a P4 with Hyperthreading, i noticed that this isn't a good idea, because it leads to threading issues (like when the timer-thread is working on a rotation-matrix the main-thread uses for rendering). This results in parts of the geometry rendered wrong or distorted for a frame. And this is exactly what i noticed when running around in the level. Note that i never experienced this on none-HT CPUs like Athlons, so it's difficult to explain and debug. Have a look at the newer version of the fps-demo to see how i'm doing it now. As a rule of thumb: Never let any other thread than the main-thread (the thread that does the rendering) modify the camera or some object's matrices. Not the timer-thread and not an Event-Listener-thread (like a Key- or Mouse-Listener) because you may run into trouble. And it's a real pain to debug this stuff...believe me... :wink:
But now back to running around in this world... :D

11720
Projects / JPCT and Applets
« on: January 19, 2004, 03:45:17 pm »
No, it doesn't support lightmaps/multitexturing but vertex lighting. You can bake your static lighting into the textures if you want to, but you have to do this yourself. The reason for not supporting lightmaps/multitexturing is performance of the software renderer. It's the price you pay for the flexibility.
About the animation: You can do keyframed animations by either creating the animation in your code (by combining several meshes into an Animation) or by using the MD2-loader to load MD2-models. Using the animation out of a 3DS-file is not supported as it would require a completely different animation framework.

Hope this helps.

BTW: What kind of game are you planning to make?

11721
Projects / JPCT and Applets
« on: January 19, 2004, 12:12:43 am »
There are some examples in the API distribution. However, they is no applet example anymore since jPCT0.97, because i decided to remove it. It's code was rather outdated. If you want to, you can still grab 0.96, which contains an applet example, from here: http://www.jpct.net/download/jpctapi_096.zip
Anyway, using jPCT in an applet doesn't really differ from using it in an application...

11722
Support / Randomly Generating Object3D's
« on: January 16, 2004, 09:44:11 pm »
Testing the ships for collision with the player should be fine. The demo i mentioned above does the same between the bubbles and the alien. It displays approx. 100 bubbles.

11723
Support / Randomly Generating Object3D's
« on: January 16, 2004, 02:53:41 pm »
Creating them at runtime may not be a good idea as it is quite costly to call build() on an object. It may be an option if the objects are quite simple though. I think it's better to add them at the beginning/setup of the level, i.e. when you know that you'll never use more than 100 objects of type x and maybe 50 of type y. Just create the maximum amount of objects for each type (try to use cloneObject() for this as it will save you lots of memory if the object's meshes are all the same), build them and add them to the world (remove the formerly generated objects for the previous level) and maybe to a pool/manager that you have to write yourself to manage the state of the objects (the pool can as well do the creation of the objects...that's an even better way of doing it). If you need a new object of type x at position a/b, ask the manager for it. Similar to a connection pool for accessing a database. This demo http://www.jpct.net/demos does something similar in a very small scale with the moving bubbles.
However, i hope you don't want to do a collision detection between all these objects, because when using 100 objects at time, this will result in something like 100*99 collision detections per step, which is a bit heavy...

Hope this helps somehow.

11724
Support / Randomly Generating Object3D's
« on: January 15, 2004, 09:20:58 am »
The amount of objects that may belong to a world is unlimited (in theory...in practise, memory usage and performance will limit it of course). However, letting the engine determine which objects are visible among 1,000s of them is not a good idea performance wise. Maybe it's possible for you to use a pre-processing stage based on the logic of your game to determine what may be visible and what isn't (divide the space into sectors or whatever...). With this information, you can either set some objects to visible/invisible as needed or remove them from the collection of objects if not needed and add them again if needed. The second solution may not be a good idea if it happens a lot, because removing them is not that cheap.
Note that you have to call build() only once on an object. It's not required to be called everytime you add it.
How much is "infinitely" in your case?

11725
Projects / fps showcase
« on: January 11, 2004, 01:43:11 pm »
:shock:  Looks great. I'll add a link to this thread to the projects page within the next days.

Edit: I've edited your first post to replace the image, because it wasn't working. If you are having problems with hosting images in the future: I can host them here on jpct.net if you want. Just send them to me.

11726
Support / Parenting the camera to an object
« on: January 09, 2004, 04:33:17 pm »
Another possible solution is to place the camera behind the object by getting the object's transformed center and translate it somehow (i.e. as needed in your case) by evaluating the results from the get?Axis()-methods of the object. Somehow like:

Code: [Select]

SimpleVector tc=object.getTransformedCenter();
SimpleVector pos=new SimpleVector(tc);
SimpleVector zAxis=object.getZAxis();
SimpleVector yAxis=object.getYAxis();
zAxis.scalarMul(5f);
yAxis.scalarMul(2f);
pos.add(zAxis);
pos.add(yAxis);
theWorld.getCamera().setPosition(pos);
theWorld.getCamera().lookAt(tc);


Please note that i haven't tested this and typed it out of my head, so i could be totally wrong here...

11727
Support / Parenting the camera to an object
« on: January 09, 2004, 04:17:27 pm »
We've covered something like this before in this thread:

http://www.jpct.net/forum/viewtopic.php?t=67

Could be bit messy to dig through it, because we had some problems with it in that version of jPCT. However, i've posted a little code-snippet at the end of the thread on how to setup that thing. Combine that with something like the code below

// Move the camera back to the cameraHolder and look at the player

from the initial posting (just using "dummy" instead of "cameraHolder" should work) and you should get what you want. If not, maybe JonnyDee is willing to help and post his solution?!

11728
News / Version 0.97 has been released!
« on: January 09, 2004, 02:41:40 pm »
"Riding around" on moving entities actually isn't a problem that can be solved with collision detection alone. It's  something the game logic has to handle. Albeit i haven't implemented it myself yet, i suggest to simply apply the transformations of the moving entity to the camera (or the object, which can be done using object hierarchies) if the camera/object collides (and that's where the collision detection can be helpfull) with the entity or is close to it or has activated a trigger or whatever.
Where the recent changes of the collision detection code help is when an entity itself moves into the radius of the collider's ellipsoid in the opposite direction of the collider's translation. Like an elevator that moves up and the collider standing on the elevator moves down due to gravity. The former code couldn't handle this case, because the ellipsoid collision detection tries to avoid collisions before they happen, but in this case there could already  be a collision when the detection starts. Now, the ellipsoid collision detection will adjust the colliders translation so that it moves out of the collision first. Due to the way how ellipsoid collision detection works in jPCT, this can only work fine when it's possible to avoid the collision by translating the collider in the direction of its current translation vector (or in the opposite direction, i.e. by multiplying it with a scalar). This is due to the fact that this method usually uses sliding planes and not (like the spherical collision approach) the face normals to adjust the translation. Well, it's kinda hard to explain.. :? ..to summarize this: You can do elevators with this modification (look at the updated fps-example) but it doesn't work as a "push me out of any collision there is"-approach. That's what the spherical approach is for.

Hope this helps!

11729
News / Version 0.97 has been released!
« on: January 08, 2004, 07:05:24 pm »
Changes are documented here: http://www.jpct.net/changes.html

Please note that this release doesn't contain the Bounce-example anymore, because i decided to remove it from the distribution.

Have fun!

11730
Support / Is it possible to change the texture coordinates?
« on: January 07, 2004, 05:33:13 pm »
At the moment: No, i'm sorry. This isn't possible. But i was thinking about this topic yesterday (what a coincidence... :shock: ) but i'm still a bit undecided how to do it. I think i have to use an approach similar to the vertexcontroller. A kind of "TriangleController".
Is this a vital feature for you or "just" nice to have.

Pages: 1 ... 780 781 [782] 783 784 ... 796