Sapphire Wand 2.0 + Doomsday 2 Hexen Models

edited 2017 Sep 11 in Addons for Hexen
Doomsday Engine 2.0 Hexen Models
wip3.png

All models here are in "beta" state and for testing purposes only.

DOWNLOAD LINK
veirdo.hexen.pack public version 9

__________________________________________________________

Installation instructions:

1. Put downloaded file inside \Doomsday 2.0.0\data folder
2. Run Doomsday Engine 2.0 executable and use Shift-Esc to reach "gear" button
3. Choose all veirdo.hexen.* packages
veirdo_hexen.png
__________________________________________________________

Package content:

Sapphire Wand HUD model
HUD_Wand_01.png
HUD_Wand_00.png

Serpent Staff HUD model
HUD_Serpentstaff_00.png
HUD_Serpentstaff_01.png

Crystal Vial model
i-vial2_01.png

Quartz Flask model
i-flask2_01.png
«134567

Comments

  • May I ask why yourself decided to redo your Sapphire Wand, over making hi-poly versions of new objects and coming back to the ones you've already done later?

    That said, I'm interested to see what more polygon's will bring to a model like the wand, as the sprite is fairly blocky/square edged (to use one term to sum up). I am assuming more polygon's will generally be more noticeable on objects with more rounded edges or engraved details (the engraved rune things on the wand are pretty simple).
  • With regard to adding more polys to the models, its mainly about improving the lighting rather than making their silhouette smoother (which is also an improvement, mind). The extra geometric detail in the high-poly version will translate to a more detailed normal map in-game, meaning that light cast over the model will lead to more realistic highlights (and one day, self-shadows).
  • Vermil wrote:
    May I ask why yourself decided to redo your Sapphire Wand, over making hi-poly versions of new objects and coming back to the ones you've already done later?
    To have a new model system work it's easier to test it on a simple asset, and Sapphire wand is perfectly fit. That said, it have all features needed for a more complex models. When a new sapphire wand will work as I expect, I can switch to the other models. DaniJ is right, the highpoly model will be used only to bake normal/occlusion maps to a lowpoly model which needed for a lighting. But I want to add some more polys to a lowpoly model also.
  • Though I'd much rather see new Actors (especially the Ettin), I'm very pleased to see Hexen getting some much needed attention. Thanks veirdo!
  • Cant wait too see Hexen and Heretic models in a new format:)
  • I'm very impressed with the xrp pack as a whole but like the other guy posted it doesn't seem logical to redo models that already look fine when we're still missing a ton of key models. I am dying to see 3d models of all the enemies such as the wyvern, heresiarch, swamp creature, frost creature as right now playing with all 3d models then seeing one of those horribly pixelated sprites really takes away from the immersion of the game.
  • true but with a new model formant coming it's also logical to build for that and redo everything as with the new format it will be easier to build for it thus in the time to get one md2 model you might have 2 or even 3. since you do not need to make compramizes to the model for the md2 format.
  • so is the new model format going to eliminate the old, or will we still be able to use what we have until the new ones come along?
  • The new package based model format is offered in addition to the older/existing model add-on formats. You'll be able to continue using existing models as-is.
  • Gordon wrote:
    true but with a new model formant coming it's also logical to build for that and redo everything as with the new format it will be easier to build for it thus in the time to get one md2 model you might have 2 or even 3. since you do not need to make compramizes to the model for the md2 format.
    This sites always changing everything every 10 minutes. If we went by that logic we'd never get anything done lol. I've been waiting 10 years for this since I first discovered the doomsday engine for a complete 3d model pack for hexen. Now we got veirdo almost completed one I'm just sayen throw me bone here...
  • i would say yes but the dev team is not but they are on bug fixing mode now so at least work on any model will likely catch up for the 1.15 release.
  • I'm continue to work with the Sapphire wand model and have a low-poly model with materials. Animation and effects coming soon :)
    wip3.png
  • Beautiful work!
  • *whistles*
    thats one extremely lovely looking wand you made veirdo <3
  • Before I did an export I should clarify some details. All the questions are for Skyjake, I think :)
    1). Model axis. I used "+X" for front and "+Y" for up. Is it correct for a new models?
    2). HUD model pivot. I used a camera-centric pivot for a HUD models before, but it works well only for a certain camera with a 4:3 aspect ratio and 95 degree FOV. Maybe it should be better to have a model-centric pivot for a HUD models and one procedurally-generated point on camera to attach to, depending on camera settings.
    HUD_pivot.png

    The next questions are about new shader. To speed up material creation and adjustment I've tried to rewrite your shader (found in model.dei) on CGFX to use it in Maya viewport. My questions are from artist's point, so they may sounds lame :)

    3). I cannot find any color information fed for vertex shader. The vertex color and vertex alpha are great support for visual effects. Did you plan to add it in the future?

    4). From line 107 I found that you pack a reflectivity to an alpha channel of the specular texture
    // Check the specular texture for parameters.
                    highp vec4 specular = texture2D(uTex, vSpecularUV);
                    highp float shininess = max(1.0, specular.a * 7.0);
    
    but I don't get why are you multiplying that by 7 for the max function?

    5). Also I cannot find any reflection maps besides a light sources fed for a pixel shader. Could we use a cube maps?

    6). At line 135 I found that you have an emissive mask with an alpha channel.
    gl_FragColor.rgb += specular.rgb + (emission.rgb * emission.a);
    
    What purpose is it for? Did you plan to make a separate UV-scrolling for .rgb and .a channels?


    7). Not a question, but a suggestion. An artists could control material parameters via skeletal animations. For instance, "joint1" translation in "X" direction could control color texture "U"-scrolling in "material1"; and "joint1" translation in "Y" direction could control color texture "V"-scrolling in "material1"; and "joint1" translation in "Z" direction could control alpha multiplier in "material1".
  • veirdo wrote:
    1). Model axis. I used "+X" for front and "+Y" for up. Is it correct for a new models?

    There is no fixed axis setup that you are expected to use. Instead, you can choose your axes as you wish and specify them in the model metadata, for instance:
    asset model.hudweapon.wand {
       path = "wand.md5mesh"
       front &lt;1, 0, 0&gt;
       up &lt;0, 1, 0&gt;
    }
    
    Those would give you +X for front and +Y for up.

    Note: The current unstable builds do not yet support "hudweapon" models, just "thing" models. I'll be working on this in the near future so we can try out your wand model.
    2). HUD model pivot.

    I think we should go with the model-centric pivot. This is what I'm thinking when it comes to HUD weapon positioning:
    • For VR / Oculus Rift, it is important that the weapon models are positioned correctly in world space, so that they appear as in "real life". That is, the weapon model should be placed in the correct size and position in relation to the player body model.
    • For replicating the appearance of the original sprites, a viewport-dependent placement of the model is more appropriate so that it remains visible regardless of the viewport size and/or camera FOV.
    • Weapon bobbing should be different in these two use cases — in VR, the traditional Doom sine wave bobbing looks stupid. The traditional bobbing can be procedurally done by Doomsday, however it also needs to be possible to specify a bobbing cycle animation so that the modeler can animate the movements of the weapon by hand.
    So this means that we'll probbaly need some model metadata settings/flags to describe how the model is intended to be used, and depending on the view mode Doomsday can then position the model appropriately. Nevertheless, I'm thinking the model author needs to size the weapon models so that they are "natural" size in the game world.
    3). I cannot find any color information fed for vertex shader. The vertex color and vertex alpha are great support for visual effects. Did you plan to add it in the future?

    Yeah, that example shader doesn't use vertex colors. It is not difficult to add them, though, and I will make it possible to use vertex colors if the model includes them.

    Note that it will be possible to specify the shader individually for each model (when needed), so we are not beholden to any one shader. The one in the test model that you found is just the one I used for testing purposes.
    4). From line 107 I found that you pack a reflectivity to an alpha channel of the specular texture but I don't get why are you multiplying that by 7 for the max function?
    I don't recall exactly tbh. Most likely that was just because the specular/shininess map that I created used a particular range of values and I simply scaled it up to suit the test case. In a "real" shader I wouldn't expect to do this kind of range alteration.
    5). Also I cannot find any reflection maps besides a light sources fed for a pixel shader. Could we use a cube maps?

    Yeah, ideally I would like Doomsday to provide a dynamically rendered cube map for model reflections but that has not been implemented yet. I will add a new texture map type for reflections, so that we could at least include static reflection maps with the models.
    6). At line 135 I found that you have an emissive mask with an alpha channel. What purpose is it for? Did you plan to make a separate UV-scrolling for .rgb and .a channels?
    That is just for testing purposes. It is really up to the shader's needs, since Doomsday doesn't have to dictate any one way to use emissive maps. Currently emissive maps are just one of the sets of texture coordinate rectangles given to the shader as input; a shader can specify which ones it uses as necessary:
    textureMapping &lt;diffuse, normals, specular, emission&gt;
    
    ...translates into...
    
        attribute highp vec4 aBounds;   // diffuse map
        attribute highp vec4 aBounds2;  // normal map
        attribute highp vec4 aBounds3;  // specular map
        attribute highp vec4 aBounds4;  // emission map
    
    (Those coordinates refer to the texture atlas of the model, which is prepared by Doomsday.)
    7). Not a question, but a suggestion. An artists could control material parameters via skeletal animations. For instance, "joint1" translation in "X" direction could control color texture "U"-scrolling in "material1"; and "joint1" translation in "Y" direction could control color texture "V"-scrolling in "material1"; and "joint1" translation in "Z" direction could control alpha multiplier in "material1".
    Hmm, interesting. Do you think the information available to the vertex shader is already sufficient for doing this, i.e., in the shader take for instance uBoneMatrices[43] and multiply that with something to produce suitable animation values that can then be used in the fragment shader as needed?


    We should prepare a modified/improved generic shader that you think is appropriate for HUD weapon models (or all 3D models), given all the artistic features you'd like to have available.
  • Is the new model format part of the upcoming 1.15 stable release?
  • PostFatal wrote:
    Is the new model format part of the upcoming 1.15 stable release?
    Yes, but there are caveats. In 1.15 stable, the new format only works with game world objects, not with HUD weapon models. My plan is to continue working on the new model format, expanding its use for more use cases (like the HUD weapons) during future unstable builds after 1.15 has been released.
  • Will there be any new models ready for the 1.15 release?
  • just wondering if veirdo is still working on the new models.....or waiting till the new model format is fully implemented...
  • veirdo has had technical problems accessing this web site recently, but he is continuing work on the Hexen models.

    The Wand model is now in good shape and waiting for HUD models to be implemented in the new renderer. I plan to continue work on model rendering after the 1.15 release has been finalized.
  • thx for the info :)
  • I am back. Although I still have no direct access to the site (all russian IPs are blocked on the site host provider), now I'm using VPN, like I'm from USA. The wand is ready for the implementation, as skyjake said, and now I'm working on an Ettin model.
  • glad to hear from you......I'm looking forward to your upcoming work.... :)
  • yo Veirdo i had a look at your particles for your 2 torches that has the unlit state and tweaked the particles so that they work as intended.
    #Flame Particles
    
    Generator {
      State = "ZWALLTORCH1"
      Flags = blendadd | modelonly 
      Spawn Radius = 2.0
      Spawn age = 40
      Max age = -1
      Vector Rnd = 1
      Speed = 0.057
      Spawn rate = 0.342
      Alt start = 19
      Alt Rnd = 0.5
      Particles = 999
      Center = { 0.0 0.0 28.0 }
      Stage {
    	Type = tex79
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 2.98 0.946 0.269 0.1 }
    	Gravity = -0.0525; 
    	Radius = 1.866
    	}
      Stage {
    	Type = tex80
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 2.782 0.877 0.257 0.529 }
    	Gravity = -0.0525; 
    	Radius = 5.536
    	}
      Stage {
    	Type = tex81
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 2.583 0.809 0.245 1.0 }
    	Gravity = -0.0525; 
    	Radius = 9.207
    	}
      Stage {
    	Type = tex82
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 2.385 0.740 0.233 1.0 }
    	Gravity = -0.0525; 
    	Radius = 12.879
    	}
      Stage {
    	Type = tex83
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 2.186 0.672 0.221 1.0 }
    	Gravity = -0.0525; 
    	Radius = 14.536
    	}
      Stage {
    	Type = tex84
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 1.988 0.604 0.209 1.0 }
    	Gravity = -0.0525; 
    	Radius = 13.44
    	}
      Stage {
    	Type = tex85
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 1.789 0.535 0.197 1.0 }
    	Gravity = -0.0525; 
    	Radius = 12.337
    	}
      Stage {
    	Type = tex86
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 1.590 0.467 0.185 1.0 }
    	Gravity = -0.0525; 
    	Radius = 11.247
    	}
      Stage {
    	Type = tex87
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 1.392 0.398 0.174 1.0 }
    	Gravity = -0.0525; 
    	Radius = 10.150
    	}
      Stage {
    	Type = tex88
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 1.193 0.330 0.162 1.0 }
    	Gravity = -0.0525; 
    	Radius = 9.054
    	}
      Stage {
    	Type = tex89
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 0.996 0.262 0.149 1.0 }
    	Gravity = -0.0525; 
    	Radius = 7.957
    	}
      Stage {
    	Type = tex90
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 0.836 0.218 0.124 1.0 }
    	Gravity = -0.0525; 
    	Radius = 6.861
    	}
      Stage {
    	Type = tex91
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 0.677 0.174 0.099 1.0 }
    	Gravity = -0.0525; 
    	Radius = 5.764
    	}
      Stage {
    	Type = tex92
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 0.517 0.131 0.073 0.786 }
    	Gravity = -0.0525; 
    	Radius = 4.668
    	}
      Stage {
    	Type = tex93
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 0.358 0.087 0.048 0.514 }
    	Gravity = -0.0525; 
    	Radius = 3.571
    	}
      Stage {
    	Type = tex94
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 0.198 0.043 0.023 0.242 }
    	Gravity = -0.0525; 
    	Radius = 2.475
    	}
      Stage {
    	Type = tex94
    	Flags = bright
    	Color { 0.06 0.0 0.0 0.0 }
    	Radius = 1
    	}
      Stage { }
      Stage {
    	Type = tex39
    	Flags = bright
    	Tics = 9.3
    	Rnd = 0.33
    	Color { 1.0 0.474 0.150 0.0 }
    	Gravity = -0.0525; 
    	Radius = 2.782
    	}
      Stage {
    	Type = tex39
    	Flags = bright
    	Tics = 9.3
    	Rnd = 0.33
    	Color { 1.0 0.423 0.150 0.5 }
    	Gravity = -0.0525; 
    	Radius = 18.781
    	}
      Stage {
    	Type = tex39
    	Flags = bright
    	Tics = 9.3
    	Rnd = 0.33
    	Color { 1.0 0.372 0.150 0.43 }
    	Gravity = -0.0525; 
    	Radius = 22.593
    	}
      Stage {
    	Type = tex39
    	Flags = bright
    	Tics = 9.3
    	Rnd = 0.33
    	Color { 1.0 0.321 0.150 0.31 }
    	Gravity = -0.0525; 
    	Radius = 15.736
    	}
      Stage {
    	Type = tex39
    	Flags = bright
    	Tics = 9.3
    	Rnd = 0.33
    	Color { 1.0 0.270 0.150 0.18 }
    	Gravity = -0.0525; 
    	Radius = 8.878
    	}
      Stage {
    	Type = tex39
    	Flags = bright
    	Color { 1.0 0.221 0.150 0.0 }
    	Radius = 2.25
    	}
    }
    
    Generator {
      State = "ZTWINEDTORCH_1"
      Flags = blendadd | modelonly 
      Spawn Radius = 5.0
      Spawn age = 32
      Max age = -1
      Vector Rnd = 1
      Speed = 0.142
      Spawn rate = 0.714
      Alt start = 19
      Alt Rnd = 0.6
      Particles = 9999
      Center = { 0.0 0.0 60.0 }
      Stage {
    	Type = tex79
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 2.98 0.946 0.269 0.1 }
    	Gravity = -0.07; 
    	Radius = 1.312
    	}
      Stage {
    	Type = tex80
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 2.782 0.877 0.257 0.529 }
    	Gravity = -0.07; 
    	Radius = 4.439
    	}
      Stage {
    	Type = tex81
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 2.583 0.809 0.245 1.0 }
    	Gravity = -0.07; 
    	Radius = 7.566
    	}
      Stage {
    	Type = tex82
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 2.385 0.740 0.233 1.0 }
    	Gravity = -0.07; 
    	Radius = 10.693
    	}
      Stage {
    	Type = tex83
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 2.186 0.672 0.221 1.0 }
    	Gravity = -0.07; 
    	Radius = 12.105
    	}
      Stage {
    	Type = tex84
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 1.988 0.604 0.209 1.0 }
    	Gravity = -0.07; 
    	Radius = 11.171
    	}
      Stage {
    	Type = tex85
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 1.789 0.535 0.197 1.0 }
    	Gravity = -0.07; 
    	Radius = 10.237
    	}
      Stage {
    	Type = tex86
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 1.590 0.467 0.185 1.0 }
    	Gravity = -0.07; 
    	Radius = 9.303
    	}
      Stage {
    	Type = tex87
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 1.392 0.398 0.174 1.0 }
    	Gravity = -0.07; 
    	Radius = 8.369
    	}
      Stage {
    	Type = tex88
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 1.193 0.330 0.162 1.0 }
    	Gravity = -0.07; 
    	Radius = 7.435
    	}
      Stage {
    	Type = tex89
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 0.996 0.262 0.149 1.0 }
    	Gravity = -0.07; 
    	Radius = 6.500
    	}
      Stage {
    	Type = tex90
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 0.836 0.218 0.124 1.0 }
    	Gravity = -0.07; 
    	Radius = 5.567
    	}
      Stage {
    	Type = tex91
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 0.677 0.174 0.099 1.0 }
    	Gravity = -0.07; 
    	Radius = 4.633
    	}
      Stage {
    	Type = tex92
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 0.517 0.131 0.073 0.786 }
    	Gravity = -0.07; 
    	Radius = 3.699
    	}
      Stage {
    	Type = tex93
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 0.358 0.087 0.048 0.514 }
    	Gravity = -0.07; 
    	Radius = 2.765
    	}
      Stage {
    	Type = tex94
    	Flags = bright
    	Tics = 2.9
    	Rnd = 0.33
    	Color { 0.198 0.043 0.023 0.242 }
    	Gravity = -0.07; 
    	Radius = 1.831
    	}
      Stage {
    	Type = tex94
    	Flags = bright
    	Color { 0.06 0.0 0.0 0.0 }
    	Radius = 1
    	}
      Stage { }
      Stage {
    	Type = tex39
    	Flags = bright
    	Tics = 9.3
    	Rnd = 0.33
    	Color { 1.0 0.474 0.150 0.0 }
    	Gravity = -0.07; 
    	Radius = 3.0
    	}
      Stage {
    	Type = tex39
    	Flags = bright
    	Tics = 9.3
    	Rnd = 0.33
    	Color { 1.0 0.423 0.150 0.5 }
    	Gravity = -0.07; 
    	Radius = 18.0
    	}
      Stage {
    	Type = tex39
    	Flags = bright
    	Tics = 9.3
    	Rnd = 0.33
    	Color { 1.0 0.389 0.150 0.43 }
    	Gravity = -0.07; 
    	Radius = 23.71
    	}
      Stage {
    	Type = tex39
    	Flags = bright
    	Tics = 9.3
    	Rnd = 0.33
    	Color { 1.0 0.321 0.150 0.31 }
    	Gravity = -0.07; 
    	Radius = 15.14
    	}
      Stage {
    	Type = tex39
    	Flags = bright
    	Tics = 9.3
    	Rnd = 0.33
    	Color { 1.0 0.270 0.150 0.18 }
    	Gravity = -0.07; 
    	Radius = 8.71
    	}
      Stage {
    	Type = tex39
    	Flags = bright
    	Color { 1.0 0.221 0.150 0.0 }
    	Radius = 2.5
    	}
    }
    

    what i did was get rid of them being a static gen as they never die and made it so the particles lasted the ticks it takes for the animation sequence to be done. so for the twined torch it take 32 ticks to get back to state 1 and for the wall torch it takes 40 and it works beautifully. now if you do not want to use what i have given thats fine. but the spawn age thing is a good tool to use for this.
  • Hi Gordon! Yeah, I was thinking the same way to have a "state"-based particle definition for lights. But that may have a problem for some levels as a "state def" may create too much particle generators and some of them may not work.
  • but how it is now already has that problem. the gens die after it's used then it respawns when the frame reaches 1. but if you have it as static then you have for every frame 1 that happens you have a gen spawning so if it loops 20 times then thats 20 new gens that are going at the same time. if you look i removed the static from thos 2 gens. and i have not had any lags at all tho wile testing i did when i did not have it right.
  • Doomsday's particle system should be enhanced to remove performance bottlenecks caused by dynamic memory allocation. Regardless if a generator is 'static' or not, linear allocation of memory in a particle system can and should be avoided.
  • edited 2015 Jun 16
    Ettin WIP
    edit: remove link
  • Gordon wrote:
    yo Veirdo i had a look at your particles for your 2 torches that has the unlit state and tweaked the particles so that they work as intended.
    #Flame Particles
    
    Generator {
      State = "ZWALLTORCH1"
      Flags = blendadd | modelonly 
      Spawn Radius = 2.0
      Spawn age = 40
      
    }
    
    Generator {
      State = "ZTWINEDTORCH_1"
      Flags = blendadd | modelonly 
      Spawn Radius = 5.0
      Spawn age = 32
    }
    

    what i did was get rid of them being a static gen as they never die and made it so the particles lasted the ticks it takes for the animation sequence to be done. so for the twined torch it take 32 ticks to get back to state 1 and for the wall torch it takes 40 and it works beautifully. now if you do not want to use what i have given thats fine. but the spawn age thing is a good tool to use for this.

    I tried your code, and received 1 FPS (was 60 FPS with veirdo's code)

    So, while we are waiting of fix of this bug http://tracker.skyjake.fi/issues/1819 and particle system enchancements, as Danij said above, I made next temporary workaround for myself: just copied original static generator to unlit torches
    Copy Generator { Mobj = "ZTWINEDTORCH_UNLIT" };
    Copy Generator { Mobj = "ZWALLTORCH_UNLIT" };
    

    I think this workaround is least from 3 evils "no particles, 1 fps and particles near unlit torches"
    veirdo wrote:
    Pretty interesting, also because this is first monster by veirdo as far as I know. I'm very curious, which animation behavior it will have (for example attack animation) in comparison to sprites (attack animations are very different from sprites in current 3d models of most of the monsters)
Sign In or Register to comment.