Does anyone know how to get faces to share a UV in max?  For example the back side of a house should have the same texture as the front?  I've seen a bunch of UV Unwraps that show just unique faces in the UV but I'm not sure how to do it.

Just for grins and giggles - here is a low quality video of it:
http://s187.photobucket.com/albums/x132/ToddMcF2002/?action=view&current=0aeb5f30.flv

Not at all.  The Werdy character was designed by my 6 year old BTW.  In crayon, not in Max.  That will stay - plus the trees with better textures.  Everything else may change but I like the heightmap look in general.

I should point out the game concept:  A kids RPG.  For example - a troll might block a bridge and demand an apple pie for passage.  Werdy will have to find the ingredients and make the pie.  I'll blit the requirements on the screen such as 2 of 6 apples found etc.  Werdy might have to do a side quest to get some NPC to give access to an oven to bake the pie.

That's the idea.  Basic main quest / side quest structure.  Lots of jumping and climbing to keep kids interested.  The roll advancement will be in the form of powerups such as jet packs and roller blades.

My kids were playing it this morning and really like it - since Werdy is rigged for running, jumping and back flipping etc.  Timed right he can jump while still falling and gain additional height to get on top of structures such as that hut.  Of course they are equally excited by walking through the skybox but hey its a start.

I installed it on my desktop 3.2Ghz x850xt and it gets about 60FPS.  The real levels will be more hemmed in but with lots of objects I think this test level is pretty indicitive of performance.  I was intentionally wasteful of the polys for the test level - you are only seeing about 20% of it in the screenshots and the plane used for heightmap is very dense.

A basic 3rd person non violent platform type.  This is just a test level for framerate, lighting and some crude landscape models.  I did all the modeling except the "hut" which was a turbosquid freebie.  The framerate is about 70-140 on my Centrino IBM T60 with a Radeon x1400.  The test level is pretty large - the OC Tree size is 30800 for the landscape alone.

 

Egon,

Are there any effects you can add to a texture without replacing the texture and causing a hardware caching?  Such as scrolling, rotating etc.

Thank you for posting the code BTW.  I never would have guessed it was so short!

That works for me as well

MP3SPI 1.9.4
JavaZOOM 1999-2005

I've settled on 100ms updates to the textures and I think its reasonable - also I'll share the texture.

I was messing around with different JPG's and its amazing the difference in effect.  Do you have a texture you could post that looked good for you?  I'm trying to figure out just how good this can look.  It reminds me of the old algorithmic textures in the original UnrealEd.

In short... I like it!

I've been playing around with WaterTextureEffect.  The confusion I have is over the intensity and when to call applyEffect.

If I set the "intensity" to 2000 (is this duration in milliseconds???) and applyEffect every 1000 ms there is cumulative effect and after about 30 seconds it is "rippling" alot.

If I set the intensity to 1000 and applyEffect every 1000 ms not a heck of alot of rippling happens, just small pockets.

Is the intensity in milliseconds?  Should I overlap the applyEffect or am I misusing this class?

My framerate went from ~400 to 70 using this effect 

It is an interesting effect though.  I was going to play around with the constructor, but what are the value ranges?  The javadoc is pretty vague on the first 3 arguments:

public BloomGLProcessor(int darkening,
                        int blur,
                        int strength,
                        int quality)

I actually implemented it last night - similiar to what you are saying Raft.   However you've reminded me I have to handle head collision.   Here is all the collision code - it essentially checks for a jump offset during its gravity calculation and accounts for the height of the jump.  Depending on the current animation frame I increment or decrement the height offset.  So its the gravity calculation itself that causes the avatar to rise and fall because of the offset.

Also I added a smoothing factor to the Y axis transition where I don't allow anything greater than 7 in either direction.  I did this because if the avatar steps off a small rise the camera jolts to follow the drastic change on the Y plane.  Also, the avatar shouldnt transition on the Y axis instantaneously, that's not gravity!  Seems to work nicely.  I also terminate the jump animation if a plane is encountered.  As an aside - the reason for the "blocking" boolean is because if the user releases the forward motion during a jump the animation wants to switch to "stand".  I need to complete the jump.  As soon as the avatar lands I release the boolean and the animation switches.  Works nicely.



public void moveForward(Object3D terrain) {
SimpleVector vnew = _main.getZAxis();
vnew.scalarMul(speed);

SimpleVector vcoll = _main.checkForCollisionEllipsoid(vnew, _ellipsoid, 5);

boolean bNoHit = (vcoll.x == vnew.x && vcoll.z == vnew.z && vcoll.y == vnew.y);

vnew = vcoll;
vnew.y = 0;
   
_main.translate(checkGroundDynamics(vnew, terrain));


}


private SimpleVector checkGroundDynamics(SimpleVector vnew, Object3D terrain){
SimpleVector vret = null;
try{

SimpleVector vdist = new SimpleVector(0, 1, 0);

float fdist = terrain.calcMinDistance(_main.getTransformedCenter(), vdist);

if (fdist != Object3D.COLLISION_NONE) {
fdist -= 10;
vdist.scalarMul(fdist - 4);

float jump_offset = getJumpOffset();

float fdiff = (_height_offset + jump_offset) + vdist.y;

// end any jump if a surface was discovered - typically jumping
// to a higher plane will cause this....
if(fdiff == 0 && _blocking_animation)
_blocking_animation = false;

// simulate gravity and smooth the jarring movement upward as well.
// this may cause some minor clipping on slopes but its too jarring without it
// making jumps hard to control.
if(fdiff > SMOOTH_FACTOR_Y)
fdiff = SMOOTH_FACTOR_Y;

if(fdiff < (SMOOTH_FACTOR_Y * -1f))
fdiff = SMOOTH_FACTOR_Y * -1f;


vnew.y = fdiff;
}

vret = new SimpleVector(vnew);

}catch(Exception e){
System.err.println("CreatureComposite::checkGroundDynamics() " + e.getMessage());
e.printStackTrace();
}
return vret;
}


private float getJumpOffset(){
SimpleVector vret = null;
try{
if((_ai.name.equals(ANIM_JUMP1) || _ai.name.equals(ANIM_JUMP2)) &&       _blocking_animation){
float fdelta = 0f;
if(_ai.frame < _ai.duration/2f){
_ai.jump_offset -= _ai.jump_rate;
}else{
_ai.jump_offset += _ai.jump_rate;
}
}

}catch(Exception e){
System.err.println("CreatureComposite::checkJumpDynamics() " + e.getMessage());
e.printStackTrace();
}
return _ai.jump_offset;
}



I'll stick with the standard calcMinDistance().  I did not notice any penalty at all for the calculation.

As an aside - I changed something structurally that took my test from ~280FPS to ~400FPS, and I was wondering what your thoughts were on this:

Using the car sample - you are calling "place" after adjusting the rotation and speed factors and then reseting the rotationMatrix and applying the new one.   The change I made was to apply the rotation directly to the object (essentially skipping the yRot tracking) and letting the rotationMatrix take care of itself.  So I dropped this code:


rotMat=getRotationMatrix();
rotMat.setIdentity();
setRotationMatrix(rotMat);


With the rotationMatrix already calculated I took "moveForward" and added the Ellipsoid Collision detection.  Here is the big change:  Once that collision translation is complete I zero out any Y axis adjustment and call the calcMinDistance() code to handle Y axis adjustment on the terrain.

So essentially its like the car sample with additional Ellipsoid detection in the same pass but without the RotationMatrix adjustment.  My FPS jumped up 100 FPS once the change was done.

Of course it might be a total coincidence.  I might have had 3DMax open or something chewing RAM and eating FPS before the change too.

Great that validates my direction.  On your elevation control in JPCT - how exactly are you controlling it?  I was thinking of using the animation frame controller - essentially calling the apex of the jump arc equal to _anim=.5f in this standard animation update routine:


if(_anim > 1)
_anim=0;
else
        _anim+=0.05f;

//check for the apex of a jump here....

this.animate(_anim, _seq);



I'd do a calcMinDistance() strait down to detect a landing if the character is jumping to an elevated (or lower) plane.  That way I can prematurely end the animation sequence if they land early, which will happen if they are jumping to an elevated plane.  I can also extend the animation if the plane is lower than the starting plane since the jump will be longer in that case. 

In either scenario the apex is still _anim=.5f.

Thoughts???

120

Possibly.  I don't know anything about Max scripting unfortunately so I don't know what is possible on that front.  I was able to scrub my looping animations using the time windows feature so I'm happy there.

I have to go back now and remove the COM height adjustment on the jump animations.  I realize now that the bounding box in JPCT is unaltered during the jump (despite the mesh jumping) so I should probably move the model on the Y plane in JPCT and have a flattened jump animation in MAX.

More fun picking frames!!!

While I'm on the topic - anyone have any experience with jump animations?  Should elevation/gravity be controlled in JPCT?  Do your models literally jump in your animations or do they just do the jump without elevation?  I don't see how you can use a elevated animated jump in JPCT if you plan on jumping up to an object.  The animation will have an unwanted arc on the way down.  Animation is starting to be a full time job!

Strange issue:

If I have a sloped plane, meaning the terrain itself is sloped, calcMinDistance with breakIfLarger works just fine.  However, if I'm running up a sloped surface that is an object on the plane, using breakIfLarger causes the slope to not be detected and I fall through to the plane under it.  This is especially true where the sloped object meets the plane.  So if I'm running down the slope, toward the bottom I suddenly fall through.

Using the "normal" calcMinDistance takes care of it - but I'm curious why this is happening?