IFL deprecated ? huh?what?whazza?

#1 @eb

I made that decision. It was based on two things...

1. IFLs made rendering all meshes slower.
2. IFLs were implemented within the shapes and not the materials.
3. Materials have frame animation.

... i chose performance over a feature that wasn't widely used.

There will be a replacement, but not in 1.1. If you need the old IFLs merge it back in or don't update to 1.1.

#2 Curious question. So now that Materials have frame animation. How does one stop the material animation on one frame? So I can do damage effects on the mesh by just choosing to play forward pause or play backwards the animation?

#3 @JesseL - Interesting idea... there hasn't been any control like that so far.

The issue is that from script you really don't have access to the material instance so you can change playback on only that one instance of that object.

If you knew your materials were unique you could add something to Material itself. Else you could probably hack something in the TSStatic and/or ShapeBase to expose that sort of API.

Fixing that issue is high on my list when we add IFL-like support back to materials.

#4 'causes slow downs without being used? ..that is an odd/funny one.

Thanks for the info Tom.

#5 So, can we get a list of the engine files that need to be updated, and which code needs to be copied over in order to "merge it back in"?

And when could we expect the new ifl-like support you describe?

#6 My solution to the lack of IFLs was to create a new shader feature. This allows you to hook into the the procedural shaders and put some of your own code. Pat Wilson has a good article Extending the Torque3D Material System to get you started.

In ::prepBatchRender, you can set the material hint to be your shape base object, like so:

rdata.setMaterialHint((void*)this);

Then, inside of YourShaderFeature::setConsts, you can use:

const ShapeBase *shape = (const ShapeBase*)sgData.materialHint;
buffer->setSafe( mHandle, shape->whateverFuncYouWant() );

Obviously, you may want to be a bit safer about that code, but you get the gist of it.

You now have a hook into the shader, and a variable based on any value you want to send from your shape base object. So instead of using setPos on a thread to control your IFL, you can control it here.

I used the forest kit's wind deformation / forest item code as a guide, so you can look at that for a full source code example.

#7 This isn't the first optimization that broke existing functionality... I guess that as a product ages we must learn new ways of doing things even if on the surface the new seems inferior to what came before.

One place that depended on the capability to start/stop ifl-type animations was in the usage of animated jet nozzles in flying and hover vehicles. We can *fake* it with animated materials but it does look stupid when all directional jets are always active. Would of been nice if an equivalent sequence start/stop had been implemented before removing an existing feature that *some* actually used. But in the end we've got the source so we can always "hack something" ourselves ;)

#8 If someone writes a good IFL replacement for T3D you can bet we will look to adopt it. Till then i just have it on my list of things work on after 1.1.

@Tim

In theory you don't really need a shader feature, but Pat's article is an excellent example of how to do that sort of thing.

For IFL its a dance between Material and ProcessedShaderMaterial to animate texcoords and/or swap diffuse textures at the right point during rendering to get the effect.

If i was attacking this today i would expanded the current texture animation support in Material to do NxN frames (instead of single 1xN strip of frames) and automatically look for a numbered diffuse texture list.

@Michael

Specifically in the case of vehicles you can still animate mesh visibility to enable jets or other effects that require material changes.

#9 @Tom

the real solution is to allow us the freedom to explicitly set an objects material at runtime:

%obj = new player()
{
  material = defaultplayermaterial;
}

%object.setMaterial(flashdamageMaterial);

That would make things ALOT easier, more flexible, and less weird.

#10 @Tom - In my case, I need to be able to control IFL Sequences from the shape base object, so looking for a file list doesn't help there. In the end though, I dropped the IFL itself, and ended up just using my shader feature to do the effect I needed.

#11 The disadvantage of using NxN frames instead of single 1xN strip of frames is that when working with huge sequences (over 100 frames),you will have to do a really huge map. This will cost a lot of time on one side. The support of this map is a pending question too.
So I think the old format of 1xN strip was the correct way to do sequence animations and the NxN frames is the correct way for particle animations.
Now T3D is moving ahead and the correct way is to leave the IFL support before moving to a better decision.It is wrong to cut ready features.
Every AAA engine supports image animation.

#12 Is there any way for you to provide the source and where it goes in the engine so we can choose either. While optimiztion is important, for the art side of a game, various animation methods are just as important.

I have tried the new animation style and it does work well, except when the animation plays for more than an hour or so, it starts to get fuzzy and shake. Hoping this will get fixed.

But again, just tell us what we need to do to put IFL back, then we can choose and everyone is happy, plus for some of us to redo all the animation now is no fun and the old way was not an issue.

Thanks

#13 Perhaps they actually did something like this for the sections related to IFL: (?)

//IFLdep start

//IFLdep end

Because..
Removing IFL just hurts. Such a feature should never be "Removed" IMO. I would simply comment it out and set named comments so we can find them to add them back in if we so desire. I'm curious as to how many FPS it was really taking away.

I do understand they want T3D to blaze..but removing features for what may be a minimal fps gain is ridonkulous. ..my opinion of course. :P

#14 Nah, IFL functionality was removed and not commented... although some bits and pieces still remain.

I'm slowly adding IFL support back into my codebase (damn the so-called "improvement"!) so here is a preliminary list of what files to compare for those who wish to do the same:

engine/source/ts/

• tsShape.h
• tsShape.cpp
• tsShapeEdit.cpp
• tsMesh.cpp
• tsShapeInstance.h
• tsShapeOldRead.cpp
• tsAnimate.cpp
• tsDump.cpp
• tsMaterialList.cpp
• tsMaterialList.h
• tsShapeInstance.cpp

engine/source/ts/loader/

• tsShapeLoader.cpp
• tsShapeLoader.h

engine/source/materials/

• processedShaderMaterial.cpp
• materialDefinition.cpp
• materialDefinition.h
• materialList.cpp
• baseMaterialDefinition.h
• processedFFMaterial.cpp

engine/source/renderInstance/

• renderMeshMgr.cpp
• renderTranslucentMgr.cpp

#15 Hi Michael,

Have you been able to get the IFL working again?

#16 I wish that I could use the IFL in 1.1 as well, has anyone determine what we need to do to put it back in? A final list that has proven to work?

#17 I just want to be able to play a material animation with
Start, Stop, Pause, Set, Go forwards and Go backwards. If I can do all of that with the current material stuff, then That to me is as good as an IFL isn't it?

#18 @Brian:

Yes I've gotten IFL's working again in one of my projects. The list of files that I had posted previously were the ones that were modified in the repo when IFLs were cut out of the engine. If I remember correctly most of it was clearly marked in the original files and/or easily recognizably as dealing with IFLs. So a simple (if tedious) compare and manual merge was all that was necessary, but some extra attention will have to be given to a few changes in the material system in other places - pointers and such.

I make no promises but if (and unfortunately that's a big if at this time) time permits I'll go back and try this with beta3 as it wouldn't be useful to anyone for me to create a dif using my greatly modified working copy.

#19 hi all,
I merged the ifl stuff from 11b1 into 11b3,
I dont have time to finished it off, so Here are the file changes.
builds no problem, but getting "no texture" on everything.
be awesome if someone can do something with it.
cheers

#20 We just got the QTwebkit working, and now we can stick any web page to any texture in the game.

Both Flash and animated GIFs are supported, so we just solved our animation issues. Performance seems good, and we are no longer restricted to animated materials which tend to crash if using more than 16 frames or so.

Might be something others want to try, QTwebkit is a bit tricky to build into your game but well worth it.

The only thing it can't do really is go to specific frames in the animation like IFLs could, but at least we can put animations in of any length and size now.