www.jpct.net
jPCT - a 3d engine for Java => Support => Topic started by: ToddMcF2002 on April 28, 2007, 10:01:54 pm
-
Does JPCT support or ignore baked in textures? If it supports it - is it more or less efficient than loading textures independently?
I know it limits how I can display my models but I was curious. Some monsters won't have any variation or equipment.
Thanks!
- Todd
-
Does JPCT support or ignore baked in textures?
I'm not sure what exactly do you mean...!?
-
Apparently you can put texture info into a 3DS file in Max. For example - I added a test model to JPCT and applied no textures but the model's creator apparently baked in some textures because he rendered with blue pants, skin tones, hair etc. I was expecting the default white/grey rendering.
I never loaded a texture - so your 3DS loader must at least partially support it.
-
Objects 3d can have a color instead of an image texture. You can do your model with a base color applied and with no texture and those color will appear on jpct.
-
Either that or you've to load the textures before loading the model with the proper names. There are several threads here explaining how to load a texture so that it fits for 3ds file which is loaded afterwards. I've never heard of textures included directly in a the 3ds-format (maybe in the max format... ???) and i've never seen such a file. So, if that is your question then no, jPCT doesn't support this. But as said, you can load them individually. First load the textures, then load the model. If you've named the textures correctly when adding them to the TextureManager, the 3ds-loader will find and use them.
-
I'm familiar with the 3DS texture references - where you load the textures first. There is such a thing as baking in textures. I'll have to experiment with it and see if it acts like material assignments as mentioned above.
I'm asking these questions because I'm concerned about this UV mapping. I have several UV maps for my model because my model is built in parts. I don't see how people texture a single UV map for an entire model at once. I can't get the UV unwrap to flatten out to something workable as a single model. So right now I have 6 distinct maps for my model and I can associate the right texture to the right body part and "addChild" to link the body parts together. The thing is - now I'm facing animations and every frame has 6 mesh objects? I havent tried it yet to see how the Object3D array presents itself. I'm assuming every 6 array elements define a single animation frame in the array?
So... the reason I'm asking about baked textures is because in the efforts to simplify texturing in Max I'm making my job in JPCT harder. Hence thinking about the baking thing.
-
Congratulations for your 100000 post! (in binary :))
I have several UV maps for my model because my model is built in parts. I don't see how people texture a single UV map for an entire model at once.
Your UV map doesn't need to be continuous, you may have islands. Also, your model's parts can share single texture, just make sure each part's uv coordinates doesn't overlap with the others. See character's uv layout here (Google for many more examples):
http://accad.osu.edu/~fkalal/753/hw2/hw.html
This concrete character is a single mesh, but it's not nessessary.
So I suggest you improve your unwrapping and drawing skills and keep your job with JPCT easier :)
Edit: Oh, and this was my 10000 post! ;D
-
I got my animated 6 part character model working last night. The class I wrote "CreatureComposite" is nicely generic so I can load multi limbed characters.
The only pain in the rear is the 3DS rotateMesh() issue. After the main object is rotated (the Torso) every limb has to be adjusted on the XYZ plane. So the class supports a debug "limb selection and movement" via the keyboard mode. It tells you the delta from its world origin - so once you get the limbs in the proper location you can record the final offset. So in the end I have an XML file that records XYZ offsets for the head, arms and legs seperately (again the Torso is the parent and only has a -Y offset to get his feet planted on the ground).
What i should do is write a quick JPCT app where the only purpose is to move limbs around into proper location and record the offsets in an XML file.
The animation mesh indexes were as expected - indexes 0-5 is the base object, 6-12 frame 1, 13-18 frame 2 etc. So if the left arm is "1" in the 0-5 sequence then you assign the animation keys 7, 13, 19 ... etc to the left arm object.
You know what? I'd MUCH rather have an easier time with the UV mapping than make life in JPCT easier. I'd argue that the industry desperately needs a 3D painting application so you can get out of this UV Mapping to 2D skin nonsense. Its been the defacto method waaaaayyy to long. I want a 3D painting app so I never have to unwrap again! For now though - I'll map a limb at a time for sanity sake.
-
There is a 3D painting application that lets you paint directly on the mesh. Deep Paint 3D is one example, I'm sure there are others also.
Following approaches are possible with Blender:
1. use archimap unwrapper (works best for architecture or non-organic objects) - it unwraps automatically and the results are usually quite nice. export the uv map and paint over it with your favourite painting application
2. mark enough edges as 'seam' and use the default unwrapper (quite good one). export uv map and paint
3. mark all edges as seam and use default unwrapper. you get polygon soup and quite messy uv layout. then use blender's texture paint mode to draw directly on the mesh (but I don't like it much (it's slow), that's why I didn't recommended it in the beginning) and don't care about the uv's.
Just suggestions, good luck with your approach ;)
-
I'll have to look into this. My approach is starting to irritate me. It has a few major downsides.
1. 20% footprint bloat. A single large mesh with 100 frames of animation meshes is 20% less bytes than 6 body part meshes with with 600 frames of animation. My approach chews up a few more MB of memory as well.
2. The limb indexes (0-5) change everytime I export. The xyz offsets are the same but its annoying when the arms switch spots for example.
3. Java complexity. I'm over the hurdle now but it is just plain complex!
My biggest issue right now is animation looping. I've got my 3rd person character running and jumping via the gamepad but the "run" loop transition has a nasty hiccup. I'll fix it tonight but its a hassle because the export process is extremely tedious. I have to "snapshot" every 5th frame to avoid an enormous 3DS file. Too bad the JPCT 3DS loader doesnt support pruning frames (ie. load every 5th animation mesh).
Actually, I think its a burden Max should handle. Now I'm going to rant a bit. The "frame" selection process in Max just stinks. I want a frame pruning function! I can't believe people sit there and manually snapshot every "n" frame by hand, or use the silly snapshot range dialog and manually select every nth frame. Testing a loop of animation stinks too. For example you can't sit there and play just frames 100-160 in a loop in Max. That would be too easy! How am I supposed to see the loop without doing a tedious export??? The "rendering" function is useless since the framerate is so low. Maybe I missed something in the GUI????
-
Deep Paint 3D looks like it is the real deal. I've got to try that tonight. Price is surprisingly (refreshingly!) reasonable ~$100.
EDIT:
I think that is the academic version. Not sure what that means...
EDIT 2:
Regarding my rant above - you can set the active time segment to debug a loop. Just in case anyone is reading this and/or cares.
-
Can't you write a small MaxScript that exports every n-th frame of animation (or search the net for a ready such script)? So you get rid of the tediousness of the export process :)
Never touched 3d studio, just theorizing :)
-
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!
-
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!
Depends on the result you are looking for. Personally I use jump animations with no elevation. I control the physics with jPCT (currently trying to get ODE to work with it) and get good results.
-
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???
-
for jumping, if i got you right, by elevation jumping you mean actually translating up your avatar instead of animating mesh upwards..
if that's the case i do use such jumping. after all you cant jump over objects otherway. here is how i do it:
i disable regular gravity calculations during jump. with some kind of position calculator i translate the avatar up using collision checks (there may be an obstacle on top of it) after it reached top position the mechanism reverses to down again using collision checks. this way it can jump over obstacles and even land on them. that position calculator helps calculating desired translations, in up part faster in the beginning, slows down and reaches 0 at top, then in down part getting faster and faster. that gives the gravity effect.
hope this helps
r a f t
-
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;
}