Archangel35757

My thinking about Cloth models... was to modify (if necessary) the openJK code to allow bolting on of MD3 models... where the MD3 models are exported cloth simulations.  Or you could create a separate bone cloth model and bolt it onto the player-- so the bones are not part of the humanoid skeleton... but it would require code changes to synchronize the playing of animations of the humanoid and the cloth objects...

@@DT85

Well... When you import the xsi files they look good... but when you export them as fbx files then import those fbx files as action sources for the animation mixer... the above mentioned anims break

 

EDIT: How would you go about fixing them?

Why can't you save the imported dotXSI files directly as action sources?  Why the export to FBX and re-import?

@@ChalklYne - do we have those JKO animations in the released animation files? If so, you could send me the list and I could try in 3dsMax to import the XSI and re-export it for you as an XSI file that Softimage can open.

looking forward to the next update.

@@MGummelt hello there.

sorry if i stress again. i have some little bug again to fix on my fighters. not much deals. i was wondering if you can give me some suggest related to this.

the first problem reguard that: dogfight against fighters TEAM_PLAYER agains TEAM_ENEMY npcs. this problem occurs also if you try to create a friendly rockettrooper NPC and fight NPC rockettrooper. basiclaly, they shoot theirself on the air and their fight with repeater. during fight they have the little problem they do fly manouvre that ... in the course of some minutes, they fly ever up, up, up and more up, until they reach the skybox or the "roof" of the level map. this is not much good to see for a starfightning because in a battle NPC will lost on the Sky. i found the incriminated functions coming by AI_SENTRY and AI_REMOTE .CPP is the maintainheight function.

This:

 

void Olon_MaintainHeight( void )
{    
    float    dif;

    // Update our angles regardless
    ////////////////////////////////////////    
    NPC_FaceEnemy( qtrue );
    NPC_UpdateAngles( qtrue, qtrue );

    if ( NPC->client->ps.velocity[2] )
    {
        NPC->client->ps.velocity[2] *= OLON_DECAY;

        if ( fabs( NPC->client->ps.velocity[2] ) < 1 )
        {
            NPC->client->ps.velocity[2] = 0;
        }
    }
    // If we have an enemy, we should try to hover at or a little below enemy eye level
    if ( NPC->enemy )
    {
        // FIXA QUESTA FUNZIONE E' QUA CHE SI SCAZZANO I CACCIA E IL COMBAT TENTE A MUOVERSI VEROS L'ALTO.
        //SENTRY
        // Find the height difference
        dif = (NPC->enemy->currentOrigin[2]+NPC->enemy->maxs[2]) - NPC->currentOrigin[2];
        // cap to prevent dramatic height shifts
        if ( fabs( dif ) > 8 )
        {
            if ( fabs( dif ) > OLON_HOVER_HEIGHT )
            {
                dif = ( dif < 0 ? -24 : 24 );
            }

            NPC->client->ps.velocity[2] = (NPC->client->ps.velocity[2]+dif)/2;
        }
        //REMOTE
        if (TIMER_Done( NPC, "OlonheightChange"))
        {
            TIMER_Set( NPC,"OlonheightChange",Q_irand( 1000, 3000 ));

            // Find the height difference
            dif = (NPC->enemy->currentOrigin[2] +  Q_irand( 0, NPC->enemy->maxs[2]+8 )) - NPC->currentOrigin[2];

            // cap to prevent dramatic height shifts
            if ( fabs( dif ) > 2 )
            {
                if ( fabs( dif ) > 24 )
                {
                    dif = ( dif < 0 ? -24 : 24 );
                }
                dif *= 10;
                NPC->client->ps.velocity[2] = (NPC->client->ps.velocity[2]+dif)/2;
                NPC->fx_time = level.time;
                //G_Sound( NPC, G_SoundIndex("sound/chars/Olon/misc/hiss.wav"));
            }
        }
    }
    else
    {
        //REMOTE
        gentity_t *goal = NULL;

        if ( NPCInfo->goalEntity )    // Is there a goal?
        {
            goal = NPCInfo->goalEntity;
        }
        else
        {
            goal = NPCInfo->lastGoalEntity;
        }

        if (goal)
        {
            dif = goal->currentOrigin[2] - NPC->currentOrigin[2];

            //REMOTE
            if ( fabs( dif ) > 24 )
            {
                dif = ( dif < 0 ? -24 : 24 );
                NPC->client->ps.velocity[2] = (NPC->client->ps.velocity[2]+dif)/2;
            }
            //SENTRY
            if ( fabs( dif ) > OLON_HOVER_HEIGHT )
            {
                ucmd.upmove = ( ucmd.upmove < 0 ? -4 : 4 );
                
            }
            else
            {
                if ( NPC->client->ps.velocity[2] )
                {
                    NPC->client->ps.velocity[2] *= OLON_VELOCITY_DECAY;

                    if ( fabs( NPC->client->ps.velocity[2] ) < 2 )
                    {
                        NPC->client->ps.velocity[2] = 0;
                    }
                }
            }
        }
        // Apply friction to Z
        else if ( NPC->client->ps.velocity[2] )
        {
            NPC->client->ps.velocity[2] *= OLON_VELOCITY_DECAY;

            if ( fabs( NPC->client->ps.velocity[2] ) < 1 )
            {
                NPC->client->ps.velocity[2] = 0;
            }
        }
        // Apply friction
        else if ( NPC->client->ps.velocity[0] )
        {
            NPC->client->ps.velocity[0] *= OLON_DECAY;

            if ( fabs( NPC->client->ps.velocity[0] ) < 1 )
            {
                NPC->client->ps.velocity[0] = 0;
            }
        }
        else if ( NPC->client->ps.velocity[1] )
        {
            NPC->client->ps.velocity[1] *= OLON_DECAY;
            if ( fabs( NPC->client->ps.velocity[1] ) < 1 )
            {
                NPC->client->ps.velocity[1] = 0;
            }
        }
    }
}

 

 

 

but if i disabled this line the fighters lost also their flight manouvre of dogfight and they fight simply silly fly 'round enemy target, like a seeker droid.

the problem is caused by chunks of code that force the enemy fight to try ever to be "at the same height of eyes height of enemy models. "

i merged up remoter and sentry question for doing this code.

the problem is HERE:

 

  // If we have an enemy, we should try to hover at or a little below enemy eye level
    if ( NPC->enemy ) blablabla

and is caused by the fab functions.

if disable the sentry code field i get by the sentry the problem is strongly reduced with remote parameters of fabs flight by is still again present, i not understand much this kind of expression:

 

dif = (NPC->enemy->currentOrigin[2]+NPC->enemy->maxs[2]) - NPC->currentOrigin[2];

        // cap to prevent dramatic height shifts

        if ( fabs( dif ) > 8 )

        {

            if ( fabs( dif ) > OLON_HOVER_HEIGHT )

            {

                dif = ( dif < 0 ? -24 : 24 );

            }

            NPC->client->ps.velocity[2] = (NPC->client->ps.velocity[2]+dif)/2;

 

can you explain a lot how works exaclty fabs and difs here?

there is some way to fix this for preserve this kind of movement removing this problem of the fighter NPC shifting to Up during a dogfight?

and there is also some better code that i can use for fighter movement during a dogfights? here is defined all my npc fighters flight movements when they have a goal or a enemy. is nice to see on a combat into a map but is again alot far for a true dogfights of games like Xwing alliance or rogue squadron3d , there is any way to improve that for create a nice battle against NPCs?  this is the last tecnical problem of my AI.

@@Archangel35757 can you give me an hand too to manage this? should be great a better dogfight code of that. :3

 

I'm sorry... I just do not have any free time. Real life has me very busy. I wish I could help... I hope you are able to figure it out. Maybe someone else here could help you. Try asking in the Discord Coding channel.

@@Asgarath83 - CONGRATULATIONS!!!

@@JaceSolarisVIII ...bitbucket is easy to use if github scares you away.

Download @@minilogoguy18 's skeleton rig and watch his tutorials.

One thing I've learned with MD3 that you should scale the model using the misc_model entity, rather than scaling it in modelling software. Other model formats (OBJ & ASE) don't seem to work as well, at least not for me. Btw if you use 3ds Max, we have an extremely decent MD3 exporter.

...just decent?

you will need to use either 3ds Max, Blender, or Softimage ModTool to manipulate the mesh objects to pose the character in the JKA root A-Pose. You will find skeleton files for these 3D programs in the Files>Utilities section. Also, check the tutorials section. Once in the A-pose you will have to weight (skin) the mesh to the skeleton bones... then export to the game format... Blender does this differently than 3dsMax or Softimage ModTool. Good luck.

really nice polished metal shaders!

Could be done easier as an NPC skeleton rather than the humanoid.

You can also use normal mapping on brushes, correct? @@SomaZ

Detail has been added to the first few areas. As I work on each area, I'm trying to imagine what the actual function of that area might be, if the fuel station were real. It helps with deciding what to add, since lots of the areas in the original level were so empty and apparently purposeless.

 

 

 

Google "Fuel Refinery" and "Naval Fuel Depot" and look at the image results for more inspiration. Looks great so far.

@@Psyk0Sith - (to my knowledge) the dotXSI exporters do not turn edges on export.

That's good, you could improve it some more by adding a single vert like so:

 

 

You might be reluctant to do so because it won't be an all quad mesh anymore but order is irrelevant in low poly models. As the budget gets lower, more triangles are necessary. As long as you have the edgeflow established you should always check the silhouette in all directions and drop single verts to smooth where needed.

Overall the mesh looks smooth enough imo. The only area left to tweak would be the lower belly in sideview. If you look at the back where the tail meets the body you have a nice sweeping curve, however when you look at the belly, it looks quite sharp and blocky.

Adding a vert where you suggest still results in all quads if you remove the top vertical edge, and ignore your two lower red diagonals... but just add another edge loop all around-- this would allow you to round out that existing bottom belly edge loop and allow for better fat roll, no? Looks great @@ChalklYne!

what is providing the structural support for the curved rails? Or are they just floating in space?

@@eezstreet, @@Raz0r, @@Xycaleth, @@ensiform, @@Stoiss, @@UniqueOne ... any of you have time to help with this?

@@DT85 - Stalactites? Rather than "radioactive glowing crystals. Maybe the lighting is realistically dark and requires judicious use of the head lamp item... NV googles wouldn't work either (i.e., no light source)

@@AshuraDX - Flying home today... how can I be of assistance?

you should do that with C++ NPC movement code... but I am not familiar with the code (sorry).

@@Jedi_Mediator - please grab the actual image link that works with IMG tags.

I'm wondering if it would be viable to have Bolt-On GLM/GLA models for things like armor, capes, robes, etc.?

 

It would require a coding change to allow bolting on of robes, cloaks, capes, additional armor, etc. and would also require having the base humanoid.gla to tell the bolt-on models what anim to play. So they would have to be animated 1-to-1 to match the base anims.

 

What do you think? Seems like then you would not have the humanoid gla burdened with ancilliary bones...

 

@@Raz0r, @@redsaurus

@@eezstreet, @@DT85

Coming back to this soon!

Yes, I am still working on it. But I've gotten sidetracked with coding/compiling 3dsMax Animatable Pivot controller and a new IKFK Solver plugin for 3ds Max 8 and up (source code from another 3dsMax artist/coder). I need both of these controller plugins for my character rig. Also will be using wrinkle maps and reflection/refraction (on @@SomaZ renderer feature list). I will post an updated pic soon. Until then... this is the last WIP screenshot: