Sapphire Wand 2.0 + Doomsday 2 Hexen Models
Doomsday Engine 2.0 Hexen Models
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
__________________________________________________________
Package content:
Sapphire Wand HUD model
Serpent Staff HUD model
Crystal Vial model
Quartz Flask model
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
__________________________________________________________
Package content:
Sapphire Wand HUD model
Serpent Staff HUD model
Crystal Vial model
Quartz Flask model
Comments
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).
thats one extremely lovely looking wand you made veirdo
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.
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 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. 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".
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: 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.
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.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.
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.
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.
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: (Those coordinates refer to the texture atlas of the model, which is prepared by Doomsday.)
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.
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.
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.
edit: remove link
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
I think this workaround is least from 3 evils "no particles, 1 fps and particles near unlit torches"
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)