id Tech Forums

id Tech 4 (Doom3/Prey/Q4) => id Tech 4 Models and Animations => Topic started by: bitterman on October 19, 2016, 11:52:10 AM

Title: Why <some things> are <going wrong>
Post by: bitterman on October 19, 2016, 11:52:10 AM
Why I don't see any differences between materials with/without unsmoothedTangents keyword?

I have two copy of .ase model (in fact it's "U"-plane) with textures/smooth and textures/unsmooth BITMAP. The textures/unsmooth contain a unsmoothedTangents keyword.
I expect that second model will be rendered with unsmoothed tangents (with different lighting along each edge).
But it's not. Why?

Thanks.

P.S. I see a r_showunsmoothedtangents in RBDOOM and then my model is colored green.
Title: Re: Why <some things> are <going wrong> (unsmoothedTangents)
Post by: bitterman on October 21, 2016, 09:16:35 AM
Picture:

1. Plane with textures/smoothed.

2. Same plane with textures/unsmoothed (add unsmoothedTangents).

3. Same plane with Edge split and textures/unsmoothed.

As I expect fig. 2 with unsmoothedTangents must looks like fig.3 with split edges.

textures/smoothed
{
    noselfShadow
    noshadows
nonsolid
noimpact

qer_editorimage  textures/gray.tga
diffusemap textures/gray.tga    
}

textures/unsmoothed
{
    noselfShadow
    noshadows
nonsolid
noimpact

unsmoothedTangents

qer_editorimage  textures/gray.tga
diffusemap textures/gray.tga
}
Title: Re: Why <some things> are <going wrong>
Post by: motorsep on October 21, 2016, 09:26:22 AM
That's because it's time to leave Doom 3 behind and start making cool maps with DOOM and SnapMap!
Title: Re: Why <some things> are <going wrong>
Post by: bitterman on October 21, 2016, 10:02:39 AM
Renegade!  :))
Title: Re: Why <some things> are <going wrong> (unsmoothedTangents)
Post by: bitterman on October 28, 2016, 11:43:14 AM
After some experiments I found that unsmoothedTangents don't used in vanilla D3 materials.
As I think now it is because that it tends to look wrong.

1 - edge split.
2 - unsmoothedTangents.
3 - default.

Pic 2 is the same with noSelfShadow keyword.

uT works via R_BuildDominantTris which try to find the largest triangle that uses each vertex (see neo/renderer/tr_trisurf.cpp). Not sure that it's works correct. The edge split method works fine as you can see.
Title: Re: Why <some things> are <going wrong>
Post by: kat on November 01, 2016, 03:12:32 AM
Don't quote me on this as it's been a long time since I looked at that particular command but IIRC it only works with LWO models because it's tied to the Maya 'bake' commands often still seen in the *.mtl files - its original purpose was to smooth tangents across mirrored models (again IIRC).
Title: Re: Why <some things> are <going wrong> (unsmoothedTangents)
Post by: bitterman on November 01, 2016, 09:58:37 AM
I was wrong. There is a piece of information about unsmoothedTangents:

QuoteThe difference arises if you use "unsmoothedTangents" in the material stage where you declare your renderBump (since the renderBump parameter on its own automatically treats the whole mesh as 1 smoothing group). As soon as you use unsmoothedTangents, then the normals will be adjusted based on the UV seams.

It's not an MD5 thing, it's just something the doom3 engine does to unify all meshes. You will find the same results on ASE and LWO. If you apply a material with the renderbump parameter then the whole mesh will be smoothed. Specify the unsmoothedTangents parameter, and it will be smoothed based on UV seams. No renderbump parameter should mean the mesh preserves smoothing group info.

http://polycount.com/discussion/54820/md5mesh-smoothing-error-this-time-with-triangles

The same model (with unsmoothedTangents parameter in material) is exported with differences UV and located in the center.
Title: Re: Why <some things> are <going wrong>
Post by: kat on November 01, 2016, 10:40:19 AM
Yeah that's the one, you need the two elements in the material/shader which is why it won't work on it's own. Only ever noticed it on LWO but good to know it does work for ASE also.
Title: Re: Why <some things> are <going wrong> (particles)
Post by: bitterman on November 06, 2016, 11:26:17 AM
Many particles are borned at same place (one particle is a image with three blades of grass).
It's gives an overlay effect.

Is there a way to spawn many static particles (like grass, hairs etc) in random positions?
("Random Distribution" is already set).

Thanks.
Title: Re: Why <some things> are <going wrong>
Post by: The Happy Friar on November 06, 2016, 12:29:16 PM
Do you mean particle emitters or a single emitter that's spread all over?

Depending on what you want to do there's a couple different ways.
a) use a script to randomly spawn particles in the area you want & use the "saveparticles" command from the console to save those to the .map file.  Just don't run the script again. :)
b) use various layers in a single emitter (or a several emitters) to achieve the look you want.
c) don't use particles, use a model.  You can export your map to a .obj & use a 3D program (like Blender) to "paint" your particles where you want them, convert them to polygons, then export all those as a single model.

I've done b& c before.
Title: Re: Why <some things> are <going wrong> (particles)
Post by: bitterman on November 11, 2016, 10:12:16 AM
Yes, thanks.

There are some troubles with creating & editing particles.

And particles system is very interesting, I don't seen any tuts about helix, radialSpeed etc before.

But anyway static particles (like grass) looks wrong at now.

Title: Re: Why <some things> are <going wrong>
Post by: The Happy Friar on November 11, 2016, 11:07:16 AM
particles aren't affected by lighting so you have to color them how you'd want them to look & not depend on the lighting.
Title: Re: Why <some things> are <going wrong> (particles)
Post by: bitterman on November 15, 2016, 11:31:45 AM
In addition to the problem with how it looks there is a unexpected problem with significant increase of loading time (one func_fx, 200 particles at same time (1000 sec.), blend add method, size 256x256 with no alpha).

Also very capricious editor behavior.

And sliders are not working in my build (they are not changes a numbers in edit field, only manual changes in field is available).

This in normal (default) behavior?
Title: Re: Why <some things> are <going wrong> (particles)
Post by: bitterman on November 17, 2016, 10:51:28 AM
 :D

About how to time increases loading time.

In simple words it creates a nested cycle like this:

FOR 0 TO 1000
               FOR 0 TO time*1000 STEP 16


So don't use a huge values for time.

// just step through a lot of possible particles as a representative sampling

for ( int i = 0 ; i < 1000 ; i++ ) {
                ...
int maxMsec = stage->particleLife * 1000; // where particleLife = time
for ( int inCycleTime = 0 ; inCycleTime < maxMsec ; inCycleTime += 16 ) {
                ...
}
}
Title: Re: Why <some things> are <going wrong> (particles)
Post by: argoon on November 17, 2016, 04:31:13 PM
Quote from: bitterman on November 11, 2016, 10:12:16 AM
Yes, thanks.

There are some troubles with creating & editing particles.

And particles system is very interesting, I don't seen any tuts about helix, radialSpeed etc before.

But anyway static particles (like grass) looks wrong at now.

I'm also making a grass system and i don't use particles i use plain old "plane with alpha" and it looks fine, just use the global material translucency, so it uses alpha blending instead of alpha testing only, sort decal so far way grass doesn't render in front and because translucent materials don't interact with light you should also use "rgb" to control the brightness of the material.

Here is my material:



textures/nature/red_strange_plant 
{
   DECAL_MACRO
   nonsolid
   noimpact
   noSelfShadow
   noShadows
   sort decal
   //twoSided
   //forceShadows
   translucent
   
   qer_editorimage textures/nature/red_strange_plant_ed.jpg
   

    {
        blend    blend
        map    textures/nature/red_strange_plant.tga
rgb 0.8 // control texture darkness -> 0 full brightness - 1 full darkness
alphaTest 0.5
    }
}
Title: Re: Why <some things> are <going wrong> (particles)
Post by: bitterman on November 19, 2016, 11:52:45 AM
Thanks for sharing. I've got a few fresh ideas.

I think about both methods (big plants via models and planes & small plants (like grass) via particles).

Particles, which are constantly oriented to the player, creating a feeling of light dizziness (vertigo).



Title: Re: Why <some things> are <going wrong>
Post by: argoon on November 19, 2016, 05:53:02 PM
I used the "deform sprite" material keyword to make them always look at the player, it worked but it automatically forced the material to no shadows and no light interaction, because i wanted the "always look at" functionality but also be able to use the material with normal maps and stuff, i removed that keyword and code my own system, only using doom script. :)

In the end i used a no light interaction material for the grass and no shadows but it was a nice lesson on idtech 4 scripting. :P

This is the small code doing the magic, perhaps there's a better way but this works and for now that is what matters.
But anyone is free to come with a better way. :)

player_angles = lod_player.getViewAngles();
player_angles_x = 0;
player_angles_z = 0;
player_angles_y = player_angles_y + 90;
lod1.setAngles( player_angles );