Hi everyone, let's start.
First, I am very grateful for all the great work that GZDoom developers have invested all these years.
And nobody should forget the many applications that have allowed us to edit, create and play the files (wad & pk3).
But unfortunately there are many complaints about 3D models:
A_Set3D +++++ should work just like the existing one (A_Overlay +++++) which in turn is an advanced version of the old and limited A_GunFlash.
A_Set3D would be the perfect solution to all problems related to your MODELDEF, as it would make precise changes and modifications of SKIN, FRAME, MODEL during the game. And to be able to use this tool in the states of actors and within functions, if a base actor who uses these new tools, all the classes that descend from him, will automatically use the 3D models already defined. Instead of unnecessarily redefining another Modeldef definition for these descendant classes.
In addition to that only A_Set3Dskin should be used to change the texture of 3D objects. And that the rest of animations work normally thanks to A_Set3Dframe.
Now, some may want to question the fact of why to suggest and add such an ambitious function as (A_Set3D + + + + + +).
I respond by saying that there are many limitations with the existing MODELDEF and that there is a lot of evidence that even internal functions and data of (GZDoom) can be modified, exported and available for ZScript. And that an topic has the power to encourage zdoom developers.
See these alternatives more easier, more faster and, above all, totally inheritable methods and that replaced some existing definitions (lump / entry) already existing and very old.
Spoiler: New Decals
The “Decal” property was implemented and in the future the A_SprayDecal. That only help a little when you want to implement stickers on the actors. These tools facilitate data inheritance since this is not possible if the DECALDEF restricted method is used:
These functions and more than the entire AttachLight, are much better alternatives than the older GLDEFS method than again, was restricted to the defined object and prevented the inheritance of information. What caused the creation of thousands of unnecessary definitions.
For a long time I wondered why when I made a programming error, the fatal error icon. It had changed.
The reason is that I think it all started when someone say a question:
It was not even a request for replacement of the sprite (MBFHelperDog: DOGSa0). or transfer files to the new zd_extra.pk3.
In the end, that topic showed that developers can make big changes to GZDoom, to help the community. In that case it was so that games can be sold without being sued by the copyright of the original doom.
And I really believe that many people need a better alternative than the limited MODELDEF.
1- the unnecessary repetition of definitions is a very common problem and most of all it happens when trying to define a change of texture in the models.
What if I try to create a 3D clay beast called "SlimeMan". And that this enemy uses the texture (SLIME0#). You would have to create about 3 additional copies of the first definition just to change the property: skin "slime0#.png".
As in the example suggested in the zdoom wiki for the “PDA Model” object:
Model "PDA Model"
{
Path "models\PDA"
Model 0 "PDA.md3"
Skin 0 "pda.png"
Model 1 "pdascreen.md3"
Path "textures\models\PDA" //this redirects the path for the next file
Skin 1 "pdas1.png" // Each redefinition includes the next frame of skin animation for this piece
Scale 3.0 3.0 3.0
FrameIndex PDA1 A 0 0 // Both the frame and screen are pieced together
FrameIndex PDA1 A 1 0
}
Model "PDA Model" //re-defining the same actor for the next frame
{
Path "models\PDA"
Model 0 "PDA.md3"
Skin 0 "pda.png"
Model 1 "pdascreen.md3"
Path "textures\models\PDA"
Skin 1 "pdas2.png"
Scale 3.0 3.0 3.0
FrameIndex PDA1 B 0 0 // the next frame is defined
FrameIndex PDA1 B 1 0
}
Model "PDA Model"
{
Path "models\PDA"
Model 0 "PDA.md3"
Skin 0 "pda.png"
Model 1 "pdascreen.md3"
Path "textures\models\PDA"
Skin 1 "pdas3.png"
Scale 3.0 3.0 3.0
FrameIndex PDA1 C 0 0
FrameIndex PDA1 C 1 0
}
Model "PDA Model"
{
Path "models\PDA"
Model 0 "PDA.md3"
Skin 0 "pda.png"
Model 1 "pdascreen.md3"
Path "textures\models\PDA"
Skin 1 "pdas4.png"
Scale 3.0 3.0 3.0
FrameIndex PDA1 D 0 0
FrameIndex PDA1 D 1 0
}
There may be an alternative if a definition is used (lump: TEXTURES) or perhaps if a (Hardware SHADER) is used.
But it would be much better to add the new ones (override void PostBeginPlay):
And just after the proposal: A_Set3Dmodel(int index, string model)
But now,
Let's say I want to create a duplicate of the slimeman enemy but this time composed of water. Or maybe, you just want a copy more resistant to damage.
Unfortunately, once you define the (WaterMan class: SlimeMan) you have to repeat all the Modeldef definitions that were already in your SlimeMan base class.
This problem can be solved effectively if these use the new tools in the animations of the original Slimeman:
A_Set3Dframe(int index, int frameIndex)
And just use the:
A_Set3Dskin(int index, string model)
With the new material composed of water.
And all this works easily with progressive (Interpolation). Since the change of (frameindex) of the model would only be visible slowly when another A_Set3Dframe. if is used the same frameindex, that would cause instant movement.
Spoiler: more comfortable transparency and Renderstyle
2- the lack and loss of Transparency in any texture used by a 3D model, is a very uncomfortable limitation.
And the only existing and recommended solution is to unnecessarily create an object that is in the same position as the original object and that this copy uses some type of RenderStyle.
This may be a good solution if applied to windows and completely static glass.
The big problem is that if the original object that constructed the copy pursues the position of another object, the transparent copy will be delayed. And this delay gets much worse if there is a large chain of objects that follow others. I already found a limited solution to this error, but that of creating copies with RenderStyle and in the Modeldef only because of the loss of transparency in 3D textures, is not at all practical.
Even so, this will not solve the fact that you cannot create a perfect fading in the textures. When using the RenderStyle (Shaded, Tanslucent) you cannot create dark and light objects in the same texture, as it happens in sprites used by regular actors. In addition to that sometimes, the transparent model is ruined and disastrous triangles appear throughout the model.
Again: A_Set3DStyle(int index, int style)
It would be a good option. Besides that it would be a visually much better option than the solution (brightmaps) for bright details on the models.
And this would be a good time to fix the issue of lost transparency.
Spoiler: some additional effects
3-There is a limit on the number of 3D models defined by each object. And the solution proposed by the Zdoom Wiki is:
zdoom wiki wrote:
While you are limited to using 4 model 'pieces' in each definition, you can re-define the same actor again to add more. This way, you are not limited to any given skin animation length, or by the number of model parts.
But I do not understand why when more than one piece is redefined towards it (actor state: Frame) do not show the two models at the same time?
It seems that the newest definition replaces the previous one, instead of being added to the group as it happens mysteriously in the player's weapons.
And speaking of weapons, A_Overlay ++++ can be used to independently add and control multiple definitions and even different types of RenderStyle. And just in case, transparency works perfectly in the 3D textures of weapons.
Another strange effect only on the weapons, is that it doesn't matter how giant the 3D model is. This will never go through the walls or even if the player is in front of a door or looks at the floor.
This particular effect would be fantastic to be able to use it:
A_Set3DFlag(int index, int flag)
Spoiler: double Modification of positions and angles
4- A_Overlay +++++ has the ability to independently control many ModelDef defined at the same time during the game. But apart from that this is only available in the player's weapons, it is not possible to control precisely the other definitions such as the position of the model and its angles.
What if I want to create a sports car. And besides, I want all your tires to roll. That they have a suspension system. And that the front address.
First, I will not only face the problem of transparent windows and the persecuted pieces. Not only will I find the limitation of available parts. And I will crash with a wall if I want to add a damage and color control function. The biggest problem is in the tires. Since I do not only have to export a demolishing Stop motion of 360 frames of each of the 4 tires since these have a logo painted in their center that would give an abbreviation of 90 frames. But I must also repeat about 360x 90 = 32,400 frames if I want to add the rotation in the front direction. And all this is just to give some fluidity to the animation. And I still don't mention the countless ModelDef definitions required, nor will I mention the suspension effect. Or the enormous work required to try to manage the countless mandatory frames on the actor to match his MODELDEF.
One solution would be to create 4 additional objects and that they perform position calculations to place where the tires are. Another solution would be to create thousands of repeated definitions that only seek to modify the angles and rotations of the tires.
Well then I'll create something more military. What if I want to build a tank. That sometimes has no wheels.
Even so, it doesn't matter if you have a heavy machine gun or a large cannon. You should always have a turret that rotates on the axis (Angle) and rises on the axis (Pitch)
And besides the tanks are generally all terrain.
And with the amazing tool to import much more complex .objland in the GZD-Builder, it is no longer possible to separate the turret and control its angles. Since the body of the tank is using some kind of angle modifier to tilt when passing through a hill or when you crush a car in a city.. Since a separate object cannot be used for the barrel, it seems that only the 360 ??frames of the model remain. Even if this does not solve the problem of the elevation of the canyon. So it only remains to define tons of uselessly repetitive definitions. Since the adjustments in the definition of 3D models are totally 6DOF. The angles, scale and position acquire the properties (Pitch, Angle, Roll) of the defined object.
All these problems can be overcome not only more easily, more quickly and in an extremely precise way.
If the A_Set3D is implemented in gzdoom, the operation would be completely inheritable to other objects that descend from a base class that uses all these tools:
Only in this incredible Gzdoom I create without limits everything I always wanted.
This request from A_Set3DModel is only to simplify the unnecessary work required to add 3D models. And surely many other people will benefit greatly from this tool and more projects based on 3D models will emerge.
Sorry for requesting something so extensive, but I really need a solution to 3D limitations.
