Gold wand (Elvenwand) HUD model+ (Links Fixed)

Psychikon

EDIT: Find the packages below with their respective licenses

Links were fixed as of September 8th, 2010
Wand+FX
Wand Ammo

I'm about to release a PK3 of the Elvenwand, associated ammos, and all their effects and particles. Say goodbye to sprites! I may have to tweak some things for the reason that I think my IWAD is messed up, 'cause I don't notice any particles for the wand, yet there are the state and thing definitions in the jHeretic.pk3, and there are also the sprites in the IWAD! I looked for videos online and there was the same deal, so I'm guessing they were redundant or something... Maybe the wand was originally intended to shoot like Daedolon's from Hexen, but they thought it easier to make it like a pistol?

http://img193.imageshack.us/gal.php?g=heretic1.jpg

1 - wand puff, wand flash, and charged wand shot trails
2 - charged wand shot trails, particles, and hit effects
3 - wand puff, and geode and crystal w/ sparkles

I made the geode to not be a flat, square box that rotates and the crystal not to be an 8-sided die that rotates on purpose. If anyone has a problem with those, I'm not going to change them, sorry. This is just to stop all the comments ahead of time. The geode is animated (like the original) with a rising light in three textures, with a fourth as the default. This way, it's not constantly flickering and looking weird. Extra states were added for this purpose: to lengthen the span of time and allow for a proper rest between shimmers.

DaniJ

Nice, I like it. Have you considered using shiny skins on the crystals?

Some advise for future projects:

In general, adding new State definitions should be avoided in these circumstances. The reason being that in an addon whose purpose is to replace the visual representation of an object; adding new State definitions is also altering the behaviour. This can have many consequences. For example, it may mean that things go a bit awry in net games because locally, the client may be animating this weapon using your adjusted State definitions but the server is using a different set of States (and given the way the HUD weapons are implemented in the DOOM engine this *could* result in problems, especially in Hexen...). At present there is no mechanism in Doomsday to prevent against this possibility (though this may change in future).

If you'd like to use a set of amended State definitions then I would suggest you make them optional; by default, not using any amended States so behaviour remains unchanged.

Psychikon

DaniJ wrote:

Nice, I like it. Have you considered using shiny skins on the crystals?

I just hadn't liked the way the shiny skins looked... Well, I could try messing around with it until it looks a little bit more natural. It's too bad we don't yet have shinemaps... It's just that the shiny skin looks a little like plastic wrap to me or something. I'll mess with it and post another screenshot, then!

DaniJ wrote:

Some advise for future projects:

In general, adding new State definitions should be avoided in these circumstances. The reason being that in an addon whose purpose is to replace the visual representation of an object; adding new State definitions is also altering the behaviour. This can have many consequences. For example, it may mean that things go a bit awry in net games because locally, the client may be animating this weapon using your adjusted State definitions but the server is using a different set of States (and given the way the HUD weapons are implemented in the DOOM engine this *could* result in problems, especially in Hexen...). At present there is no mechanism in Doomsday to prevent against this possibility (though this may change in future).

If you'd like to use a set of amended State definitions then I would suggest you make them optional; by default, not using any amended States so behaviour remains unchanged.

Thanks for that. I guess in the default setup, it would also have no custom animations for readying and putting away the weapon as well? I had to add a state (I think) for that, because otherwise it would play on a loop after the character had keeled over.
You know what might be useful in such circumstances? Rather not that the model animations are necessarily based on the states, but on state groups or actions or something, (which might also make more sense for more complex multi-part models in the future of Deng - think QIIIA-style player models) so that the animations might be extended further, so that the extra maulotaur, D'Sparil etc. states are also unnecessary.
Do you suppose that this will be possible in the future of Deng?

DaniJ

Psychikon wrote:

I just hadn't liked the way the shiny skins looked... Well, I could try messing around with it until it looks a little bit more natural. It's too bad we don't yet have shinemaps... It's just that the shiny skin looks a little like plastic wrap to me or something.

You are of course free to create your own shiny skin and customise how it is drawn in the model definition (the strength of the shine can be less than 1.0 for example so that the primary skin is drawn first and the shine drawn over it. The speed of relative rotation and the minimum colour (glow in the dark!) of the shine can also be configured).

Psychikon wrote:

You know what might be useful in such circumstances? Rather not that the model animations are necessarily based on the states, but on state groups or actions or something, (which might also make more sense for more complex multi-part models in the future of Deng - think QIIIA-style player models) so that the animations might be extended further, so that the extra maulotaur, D'Sparil etc. states are also unnecessary.
Do you suppose that this will be possible in the future of Deng?

Yes I'm well aware of the issues with the current set up. Having been on both sides of the fence I can appreciate the problems faced when trying to author models.

The core of the issue is that in DOOM, the State sequences define not only behaviour but also how a given object is animated. The Doomsday engine goes some way to decouple these two uses (for example, a model animation can have a different number of frames to the sprite-frame sequence as specified using the States) but at present they are still intrinsically linked.

You may have noticed in the New world rendering article at the wiki there is mention of a skeletal animation system. In the process of implementing such a system I expect that it will be necessary to finally separate the dual purpose nature of States.

It is likely that we will need to devise a system whereby keypoints can be extrapolated from State sequences dynamically at runtime (in the instance where a keypoint dataset has not be provided; this is necessary because of support for legacy stuff like DeHackED patches). These keypoints would then be used in description of animation sequences (creating a loose binding between the two) (so when animating you only considering animation between two keypoints). Consider then that when animating, the model renderer only has to worry about interpolating model frames between keypoints (from current model frame to target keypoint). This then suggests that it would be relatively trivial to allow the model author to define additional animations that are to be used when animating between certain keypoints (for example, when transitioning between a monster's attack and pain sequences; additional frames could be introduced in this specific transition reducing the artefacts introduced by directly interpolating between the current and start frames of said sequences).

Once such a system is in place you'll then be able to do much more with the model animation sequences without resorting to altering States.

Psychikon

DaniJ wrote:

You are of course free to create your own shiny skin and customise how it is drawn in the model definition (the strength of the shine can be less than 1.0 for example so that the primary skin is drawn first and the shine drawn over it. The speed of relative rotation and the minimum colour (glow in the dark!) of the shine can also be configured).

Minimum colour?! Let me see if I've got this straight:

df_specular -> causes a shiny skin to have a rotation reaction
df_litshiny -> causes a shiny skin to be on a fullbright model? (or is that the flag for minimum colour? in which case, how does it change the rest of these?)

Shiny -> The transparency of the shiny skin
Shiny skin -> the skin - duh!
Shiny reaction -> the relative rotation
Shiny color -> I thought that was the color of the luminosity in the shiny skin

DaniJ wrote:

Yes I'm well aware of the issues with the current set up. Having been on both sides of the fence I can appreciate the problems faced when trying to author models.

The core of the issue is that in DOOM, the State sequences define not only behaviour but also how a given object is animated. The Doomsday engine goes some way to decouple these two uses (for example, a model animation can have a different number of frames to the sprite-frame sequence as specified using the States) but at present they are still intrinsically linked.

You may have noticed in the New world rendering article at the wiki there is mention of a skeletal animation system. In the process of implementing such a system I expect that it will be necessary to finally separate the dual purpose nature of States.

It is likely that we will need to devise a system whereby keypoints can be extrapolated from State sequences dynamically at runtime (in the instance where a keypoint dataset has not be provided; this is necessary because of support for legacy stuff like DeHackED patches). These keypoints would then be used in description of animation sequences (creating a loose binding between the two) (so when animating you only considering animation between two keypoints). Consider then that when animating, the model renderer only has to worry about interpolating model frames between keypoints (from current model frame to target keypoint). This then suggests that it would be relatively trivial to allow the model author to define additional animations that are to be used when animating between certain keypoints (for example, when transitioning between a monster's attack and pain sequences; additional frames could be introduced in this specific transition reducing the artefacts introduced by directly interpolating between the current and start frames of said sequences).

Once such a system is in place you'll then be able to do much more with the model animation sequences without resorting to altering States.

With such a setup, do you think it might be feasible to keep interpolation between certain "frames" or shapes of the model itself (for facial expressions etc)? For instance, to keep the mouth somewhat smooth when moving, I had a shape driven to the jaw bone to where it drew back the lips etc. when the mouth was opened, and somewhat pursed it to close it better when it was closed.

Psychikon

OK, since I promised to upload screenshots of the shiny skin, here they are:

Speckularz ZOMG!!~!11

DaniJ

To be honest, I don't think you are making particularly good use of the shiny skin.

Perhaps try to approach the crystal in a similar way to the throwing bombs in the jXRP (i.e., translucent and glass-like). The primary skin mostly being used to control opacity (fully opaque on the edges but nearly transparent at the center of the faces) with the shiny skin then blended additively over the top (using both df_specular df_litshiny) and perhaps using a little bit of Shiny color to give it tiny minimum colour (and thus glow in the dark slightly).

Psychikon wrote:

With such a setup, do you think it might be feasible to keep interpolation between certain "frames" or shapes of the model itself (for facial expressions etc)? For instance, to keep the mouth somewhat smooth when moving, I had a shape driven to the jaw bone to where it drew back the lips etc. when the mouth was opened, and somewhat pursed it to close it better when it was closed.

I'm not entirely sure but I suspect you are referring to what is known as "morph targets"? Doing morph targets in real time basically requires GPU T&L, with the transform requiring a somewhat complex procedural vertex shader.

If that is the case then I doubt we'll be going that far with the new model animation system this rewrite (though moving T&L to the GPU is part of the plan). However nothing is decided yet as the renderer rewrite is but a blip on the horizon, so-to-speak.

Tea Monster

Got to say love the particle effects and the skin work.

I tend to agree with Dani that the gloss work dosen't really come off that well.

Love the mesh and skin though. Nice to see someone working on Heretic!

Psychikon

Tea Monster wrote:

Got to say love the particle effects and the skin work.

I tend to agree with Dani that the gloss work dosen't really come off that well.

Love the mesh and skin though. Nice to see someone working on Heretic!

Good to see you on here finally!

@DaniJ:
OK, OK! I was actually thinking that, to be honest... What is the difference between specular and litshiny, anyway? They didn't seem to have any different effect when I was messing around with them, and as far as the documentation goes, it's merely there as a flag, but it doesn't have any description for it. Also, I don't think the "twosided" flag is even in the documentation... I didn't want to bother you with the trivial stuff, just that I spent a few hours messing with it, and I thought "I just don't think I'll figure it out" and so that's why I'm asking - not to try and bother or anything like that!

I'll try it out and then post screenshots, but it might be by tomorrow, since (yet again) it's almost the end of the day for me Sorry to make you twiddle your thumbs all day... (

EDIT: like this?



you can see the fingers!

DaniJ

They say a picture is worth a thousand words... here is a rough example of the kind of thing I was getting at with my description for the primary skin of the wand crystal (naturally I had to guess your uv layout):

With a dynamic (additive) shiny texture over the top I think it might look pretty good.

As for your questions about those model flags; I will double check their purpose (its been a long time since I actually used this stuff) and update the wiki documentation.

Psychikon

DaniJ wrote:

They say a picture is worth a thousand words... here is a rough example of the kind of thing I was getting at with my description for the primary skin of the wand crystal (naturally I had to guess your uv layout):
With a dynamic (additive) shiny texture over the top I think it might look pretty good.

As for your questions about those model flags; I will double check their purpose (its been a long time since I actually used this stuff) and update the wiki documentation.

So, I think what you're saying is then just a layer of streaks and whatnot over a completely transparent background, except for around the edges?
If you set the Shiny Reaction to 0, it shouldn't move when you move the model around... So do you mean putting a "glow-in-the-dark" shiny skin on like that, then? So that it just shines in the dark? lol... I'm so sorry that I don't get what you're saying... I figured that the specular wouldn't do, and so I made the texture somewhat glittery already, but of course unless it's somewhat shiny, it's not going to look very convincing. I'll have to look at it tomorrow and find out what to do with it...

Psychikon

DaniJ wrote:

As for your questions about those model flags; I will double check their purpose (its been a long time since I actually used this stuff) and update the wiki documentation.

I did do a little of updating on the flags, just adding the "df_twosided" flag and a few descriptions for some of the flags.
Also, I've been working on updating the monster reference. I have a copy of the Hexen manual, and I've gotten the Afrit and Centaur/Slaughtaur ones done in the same vein as the other monsters, but I was curious as to whether I should leave the "Raise" state set there, or just replace it with the Frozen set, rather than merely adding it.

DaniJ

I'm not entirely sure if we want the definitions for the various game entities in the wiki at all really. Those pages were intended more as a playing guide/aid than a mod authoring reference.

Psychikon

DaniJ wrote:

I'm not entirely sure if we want the definitions for the various game entities in the wiki at all really. Those pages were intended more as a playing guide/aid than a mod authoring reference.

::dies:: hours gone to waste...
lol
I didn't realize, 'cause that's how the rest of them were defined

Psychikon

The HUD/FX and Ammo packages can be found here:

http://rapidshare.com/files/273151867/H ... 090829.pk3
http://rapidshare.com/files/273153889/A ... 090829.pk3

They are licensed particularly...

Anyhow, I hope you like them!

PS- The shiny skin was the best I saw fit. I'd tried the suggestion Dani made and messed around with the different settings as well, but they didn't seem to work as well as I'd hoped. The happy medium (for myself) I put out, because the others looked quite detestable to me when put into action.

PostFatal

Ok, I'm a late commer to this discussion. But I think I see what he is saying about the wand using a crystal. You probably shouldn't use a surface at all, but rather something that comes from within. It is a crystal after all. Maybe something glasslike with a power that emminates from it's center. Maybe I'm pushing things but I think if the engine can do it then it should be pushed. I think that because these are old games then people want to hold on to old hardware. It's 2009 and we are on the verge of dx11 not to mention the latest openGl. Microsoft dropped a lot of support for things that they thought were outdated. Maybe Doomsday should do the same.

PostFatal

This is a P,S, to my last post. I have seen a bit of discussion about how Doomsday should support certain mods that were made for other ports. So how about a group getting together to make a mod for Doomsday? Why not push Doomsday to it's limits and show it's guts. New textures and models are cool but if Doomsday can do more then let's show it. Just my 2 cents.

Psychikon

PostFatal wrote:

This is a P,S, to my last post. I have seen a bit of discussion about how Doomsday should support certain mods that were made for other ports. So how about a group getting together to make a mod for Doomsday? Why not push Doomsday to it's limits and show it's guts. New textures and models are cool but if Doomsday can do more then let's show it. Just my 2 cents.

You know what? That sounds like a very swell idea, even for when we get the new things. You know, like a DEng Showcase Level!

JonusC

PostFatal wrote:

This is a P,S, to my last post. I have seen a bit of discussion about how Doomsday should support certain mods that were made for other ports. So how about a group getting together to make a mod for Doomsday? Why not push Doomsday to it's limits and show it's guts. New textures and models are cool but if Doomsday can do more then let's show it. Just my 2 cents.

The main reason I joined here/donate to Doomsday is because I hope to create a standalone game in Doomsday engine, reminsicant of say Action Doom 2 for example.....

....i've been busy with real life nonsense though as of late, but am still keeping track of Doomsday development. The other thing is, I am really only semi-good with texture design, and also not to bad with sound/music production. I can't do maps and models.

Either way, I'd like in too <:-P I also have the webspace for it and have been working on a Community-driven website for Creative Designers for nearly a year, due to release within the next few months. So if you ever need a hosting solution, look no further [P.S. I'll never charge money to Doom fans unlike someone else *cough*] haha

EDIT: Not sure if the Deng team thinks highly of that idea, but it'd purely be a Doomsday-focused mod/experiment/project site and might help keep these boards "clean" for releases and technical, engine-specific discussion... eh it's just an idea.

Psychikon

JonusC wrote:

I can't do maps and models.

Hey, have you ever tried to make a map with a decent editor? For instance, Doom Builder?
Oh man, it's got to be the easiest modding anyone can do for a game. The only thing easier would porobably be editing NES ROM levels in a hex editor, or maybe using pre-made sprites to make a level in Game Maker.

I used to use EdMap a long, long time ago, and I don't remember it having a grid snap function.

JonusC

Psychikon wrote:

The only thing easier would porobably be editing NES ROM levels in a hex editor, or maybe using pre-made sprites to make a level in Game Maker.

I've never done either of those things in my entire life, you mad-man!

)

I really do not know if you are being serious or not there, but I have looked at Doom Builder and it doesnt appear too complex relatively speaking - I just never tried it.

Psychikon

It's not too difficult...

All the areas are sectors and they're made up of linedefs (or sidedefs). It's basically like drawing out a blueprint of a level. Sector tags make for the flickering lights, poison damage, etc. They are also the triggers to secret areas. Linedef tags are for switches and triggers, teleporters and exits, lifts and all of that.

In linedef mode in Doom builder, you just double-click to make a vertex, and then click each point to make a new line to that location. It's like drawing in geometry class!
Just make sure you have put a player start thing in, and make sure it's within a box, and that's the simplest level you can do!

Actually, to make it even simpler, stick him in a triangle...

Once you mess around with it and get used to it, it's like SOOOOOO easy...

In NES ROMs, usually levels are mapped out on a byte-per-tile grid. So you just go in there and change the bytes on the grid, and it changes the tiles in the game! That and text-editing are teh uber EZ!

Game Maker is a little more complex, but for 2D games, I dare say I haven't seen it beat. I never actually finished anything in it, though...

JonusC

Well when you say it like that, it sounds sinch! Now, back on topic... :P

Psychikon

JonusC wrote:

Well when you say it like that, it sounds sinch! Now, back on topic... :P

Yes, yes!
...and to finalize this thread (I think), the download links are at the beginning of this thread.

it's at 5 downloads compared to 15 on the gargoyle and afrit

KuriKai

Uploaded the wand and ammo models to files.dengine.net
Sad to see that it is licensed under "No Derivative Works" TT_TT

JonusC

KuriKai wrote:

Sad to see that it is licensed under "No Derivative Works" TT_TT

Aww.. Creative Commons licence? That's not too bad... i'm sure we can still ask Psych for permission if anyone had a specific modification idea, right? *wink*

I'm sure that's just for his own protection - so someone doesn't rip it off (without him knowing), change a texture, then re-release it packaged for a different source port.

I'm gonna try this out today Psych

Psychikon

JonusC wrote:

KuriKai wrote:

Sad to see that it is licensed under "No Derivative Works" TT_TT

Aww.. Creative Commons licence? That's not too bad... i'm sure we can still ask Psych for permission if anyone had a specific modification idea, right? *wink*

I'm sure that's just for his own protection - so someone doesn't rip it off (without him knowing), change a texture, then re-release it packaged for a different source port.

I'm gonna try this out today Psych

Well not only that, it DOES mention in the license that someone can ask the author for a waiver on any part or all of the license for themselves. The whole reason is just to discourage people from not using their creativity and/or learning in the process.
The DEDs are not under a no-derivative-works license, so that original file can be changed, and if anyone wants to use the models on a different port, I would definately allow that. I'm not trying to be a model miser or anything...
I've heard a horror story of someone using a friend of mine's model without their permission when they went to a job interview...yikes! :-O