3DS baked textures?

Started by ToddMcF2002, April 28, 2007, 10:01:54 PM

Previous topic - Next topic

ToddMcF2002

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

EgonOlsen

Quote from: ToddMcF2002 on April 28, 2007, 10:01:54 PM
Does JPCT support or ignore baked in textures? 
I'm not sure what exactly do you mean...!?

ToddMcF2002

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.


Melssj5

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.
Nada por ahora

EgonOlsen

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.

ToddMcF2002

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.


halcor

Congratulations for your 100000 post! (in binary :))

QuoteI 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

ToddMcF2002

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.



   
 

halcor

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 ;)

ToddMcF2002

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????



ToddMcF2002

#10
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.

halcor

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

ToddMcF2002

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!


Remo

Quote from: ToddMcF2002 on May 09, 2007, 05:19:23 AM
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.

ToddMcF2002

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???