Models, Animation, Particles and Emitters

Questions specific to OpenMW-CS can be asked, and content development related topics can be discussed here
Post Reply
User avatar
Frik
Posts: 124
Joined: 20 Dec 2016, 05:22

Models, Animation, Particles and Emitters

Post by Frik »

I've been looking at a some of the really cool models released by the UIX team over at Titans of Ether site, and trying to get some of them into OpenMW, while attempting to learn how they work. I was able to pull a basic Jade Sword into OpenMW, which worked great, but when I got to some of the models that included particles and animations, I started having trouble.

One example is the Ice Wand, or what I'm calling an Ice Mace. I copied the mesh and textures over to my working mod folder, then pulled it up in NifSkope where everything, including the animations, worked perfectly.

Nifskope (click to enlarge)
Image

However, when I pull the same mesh and textured into OpemMW-CS or directly into OpenMW, everything works, including animations, with the exception of the texture of the ice particles. Instead of being blue, they turn out pink. It's not the solid pink box that I get if the texture is missing. The texture is there. It's just pink in color.

OpenMW (click to enlarge)
Image

I know I'm missing something here, perhaps a script or activator or something. I just can't figure out what's missing or what I'm doing wrong. Any help would be most appreciated.

Thanks!
User avatar
sjek
Posts: 442
Joined: 22 Nov 2014, 10:51

Re: Models, Animation, Particles and Emitters

Post by sjek »

Image

with a quick look the niflipcontroller might not be finding those incremented textures. otherwise nialphaproperty has flag 237 which according to notes is normal
237 - the easiest and curve. It is used in all models of default with transparency, in addition to the particles. No luminosity in the dark. Overlay polygons on alpha can be seen in full.
-- google translate

which fits well to loading code in https://github.com/OpenMW/openmw/blob/m ... .cpp#L1713

Code: Select all

                        bool noSort = (alphaprop->flags>>13)&1;
                        if (!noSort)
                            stateset->setRenderingHint(osg::StateSet::TRANSPARENT_BIN);
                        else
                            stateset->setRenderBinToInherit();
as good as understand the »13 part and assume as there's no mark on 'no sorter' flags menu it goes to inherit...

that superspray seems to come from 3d max plugin, nirotatingparticles links controller and texturingproperty together and doesn't seem to be linked otherwise.

......
does changing the 'no sorter' option on in flags make any difference ?

edit:
[*]--the flip textures with overall time are defined in niflipcontroller -> texture -> edir flip controllers
[*]--material has alpha 1.00 so that is set as visible but the colors are ignored in this case (maybe non set or as default)
[*]--then the individual size can be only set in max in vanilla if understand correctly, buggy otherwise as well the radius in NiRotatingParticlesData, the upper niBSparticleNode's scale being more usable.

[*]--hmm.. there isn't niAlphaController linked to niMaterialProperty or in the niAlphaProperty and the upper niRotatingParticles is also referencing the same property so the flag seems to responsible for transparency

edit2:
the size might work as there's values read from niParticleSystemController
and at least horizontalangle is feed to particle.hpp/cpp in nifosg. as well the size, but it goes trouth data collection or that what it seems to be via
Spoiler: Show
which is then used in particle.cpp on growfadeaffector by summation but quessing that one xP

Code: Select all

void GrowFadeAffector::operate(osgParticle::Particle* particle, double /* dt */)
{
    float size = mCachedDefaultSize;
    if (particle->getAge() < mGrowTime && mGrowTime != 0.f)
        size *= particle->getAge() / mGrowTime;
    if (particle->getLifeTime() - particle->getAge() < mFadeTime && mFadeTime != 0.f)
        size *= (particle->getLifeTime() - particle->getAge()) / mFadeTime;
    particle->setSizeRange(osgParticle::rangef(size, size));
}
User avatar
Frik
Posts: 124
Joined: 20 Dec 2016, 05:22

Re: Models, Animation, Particles and Emitters

Post by Frik »

Thanks for your response. I was able to make some progress but it is still a bit buggy. There are 7 textures for crystals: sw_eq_icepart00.tga - sw_eq_icepart06.tga. But, there are no textures named: icepart00.tga - icepart06.tga. Making copies of sw_eq_icepart0x.tga and renaming the copies to: icepart0x.tga gave me a total of 14 textures. This worked to eliminate the pink color I was getting. Nifskope did not need the extra textures without the prefix: sw_eq_ , but OpenMW/OpenCS did.

I still have a few problems with model. It takes several seconds for the animation to start playing. Moving along will sometimes cause the animation to stop for a few seconds before coming back. The strangest problem is that the luminosity can change as I move. Even a slight move can cause the luminosity to change. It seems to rotate through 3 different luminosity levels.

#1 - This seems to be close to the correct color & luminosity, at least in this lighting.
Correct Color &amp; Luminosity
Correct Color & Luminosity
#2 - Move a little, the luminosity brightens & color fades
Increased Luminosity
Increased Luminosity
#3 - Move again and sometimes the luminosity brightens to max & color fades more
Max Luminosity
Max Luminosity
#4 - Same as #1 but with different (brighter) room lighting.
Different Lighting
Different Lighting
Thanks for any suggestions on how to proceed.
User avatar
sjek
Posts: 442
Joined: 22 Nov 2014, 10:51

Re: Models, Animation, Particles and Emitters

Post by sjek »

Image

would suspect optimisation problems.
otherwise seems like he has tried to add glow textures to flip textures as the icepart00.tga is defined as glow
in NiTexturingProperty.

openmw difference in this case would be probaply noticing only the first niFlipController which contain those nonexixtent glow flip textures. thought is the problem specifically in file reading order getting the main node first as the niFlipController inside niFlipController is rendered in vanilla first or is multiple niFlipControllers inside same niTexturingProperty / sub-branched together supported. there doesn't seem any way to link flip textures as glow specifically. illy's alchemy apparatus mod http://download.fliggerty.com/download--1054. she got some problems with those in bethsoft forum time ago making hot coal with flips.

the glossiness is defined in niMaterialProperty and in this case it would seem to overlap with one another. not sure how the particles are defined but keys in emitters has different values althought otherwise structure seems to be copypasted from modeling side. those are anyway read in (only 3 "key" search matchs in particle.cpp)

Code: Select all

void ParticleColorAffector::operate(osgParticle::Particle* particle, double /* dt */)
{
    float time = static_cast<float>(particle->getAge()/particle->getLifeTime());
    osg::Vec4f color = mData.interpKey(time);

    particle->setColorRange(osgParticle::rangev4(color, color));
}
osg::vec4f being "uses include prepresentation of color coordinates" in osg docs. haven't checked niKeyframeData loading today though.

and for the animation playing inconsistenly it seems that emitters niKeyframeControllers has flag 12 and niParticlesystemControllers has flag 8 and notes states
Common features of all controllers, so-called "base unit" in the date which indicates a unique parameters for a specific controller.
 
Flags - important! This is equal to all the other controllers.
    12 - cyclical animation. Those. Playing only once, without repetition.
Until restarted, the next group of animation creature or object.
    8 - constant animation, without pauses and stops.
It can work even after the death of beings, if the node flag NiBSAnimationNode and 42.
    10 - Ping Pong animation, ie, Back and forth.
Reaching the end of the cycle, will return to the beginning. News for texture controllers.
    0 - the animation is disabled, the controller is not active!
* Set PCM can be on the line flag. Or, just put the desired value.
* In some cases, it may need to change the flag from 8 to 12, or vice versa.
* For objects with a group of animations (being activators) flag 12, otherwise it will play continuously!
* For objects with a constant animation - 8.
--google translate


so if openmw reads those cleanly it might cause emitter and particles fight over each other at runtime.
generally thinking that nodestructure needs cleanup
nights zP

-----------------------------------------------------------------

Edit: got to do test runs on vanilla taking things out piece by piece and its possible to do two flip textures on top of each other. Then also vanilla complains about missing textures and shows them initially white as not finding the textures on second niflip. Have to check that flickering again. Fortunately its on same node number so remove branch deletes it's everywhere.

Also setting all controller flags seemed to have no effect as it was showing almost non in first person and triggered only to show with third person view. Picture plog is good to have.

In the end the plane 01 removal didn't have any effect as such with keyframe nodes removal and sgokeep although that is in newer game documentation to forceupdate on sudden change. Then the emitters didn't need any subnodes as the node itself defines in rotation the direction particles making that effect by circling them around the head. Notes had something about direction support.

As such the trishape containing nodes could probaply be combined in blender but re uv mapping is probaply needed so not so worth it if not wanting

Emitters and particlenodes are binded together by order althought need to search still for linking method itself. The particlenodes containing rotation is next. Textures were kinda rightforward. If you remove the texturenodes altogerher it's smoke like foggy particles.

------------------------------------------------------------

edit2: well that is kinda it's own area. WIP.
Image
paint skills with euler angles :D
https://en.wikipedia.org/wiki/Euler_angles one for each axis.
they are used for defining emission direction in emitter ninode.
vanilla takes only two as there's also other rotations (mostly in niparticlesystemcontroller, vertical, horizontal | angle, direction, allowing creation for single particle stream per controller)

http://mw.modhistory.com/download-51-15319 magic diversity's maker taggled these for weeks and there's interactions that crash vanilla but not openmw, so probaply running this test case for sake of simplicity / sanity xP

----------------------------------------------------

edit3: http://www.fliggerty.com/phpBB3/viewtop ... =31&t=3669 this one might help. rotate and setangle affects all particles from effected object. kf's seems to be only way to get "dynamic" particles while emitter is moving but there's also hardcoded magic in vanilla determining that possibly to only certain object types.

otherwise it's kinda how effects can be triggered.
.
.
On weapon particles there's some technical limit how many on what settings can be shown on first person. otherwise y can get them following the weapon setting Follow=true as NiStringExtraData under emitter ninode including that you have all scales set to 1.0
only size in NiParticleSystemController should be used.

on vanilla

slof's tutorial part 4 has keys listed for them. working with niplanarcollider and sphericalcollider could be easier in 3dmax as nifskope haven't proper values or in easy customisable form.
http://www.angelfire.com/trek/theslof/morrowind/
Animated Tells Morrowing that the particles are animated. Add to particle systems!
Mobile Add this if particles will be moving.. Like on a weapon. Add to particle systems!
Follow Should the particles cling to their position and use the objects pivot?
If False the particles will stray if you move. Add to particle systems!
Clamp Makes the particle emitter freeze on frame 0.
animated is probably same as flag 42.
i should be able to customise that weapon mesh for you by now ....... xP

------------------------------------------

edit4: well. https://dl.dropboxusercontent.com/u/555 ... or_van.NIF this works in vanilla
keyframes are deleted as those are not used if not used as thrown projectile.
flag 170 in NiBSParticleNode allows the particles to show up from the start when wielding,
and all particles are now on 1 emitter with vertical angle circling it around emitter from the side flipped with niBSparticlenode rotation.

openmw is ignoring them in some stage. the illumination problem is probably from different alpha calculations for transparency sorting.

..... :shock: xP
original has particles dynamical ie. not moving by weapon angles.

edit5:
flag 42 in NiBSParticleNode causes those particles to be dynamical but it's unpredictable in vanilla 1rst person and with openmw also in third person camera.. so it's coded some way or another

with 23.2 nightly seems to be better particles showing up. emit rate and vertical angle though for later testing
Post Reply