Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Recommended Posts

7 hours ago, kdoom said:

I appreciate that thought, but I'm an old mapper, not a legend. Iv'e seen many mappers from way back that are better than my work.

 

You may want to read that again:

 

On 7/16/2018 at 2:10 PM, Catpho said:

Haha, there’s something special about watching what I consider a mapping legend learn new mapping tools.

 

I can only speak for myself, but your maps have a "something" that made them stay in my memory, even if they're not the best of the best. Intentional or not, it's a seal of originality that not everyone has.

Share this post


Link to post

A little more progress. I know this might appear understated as far as architecture, but thats always been my style.

 

 

Edited by kdoom

Share this post


Link to post

Ok, I've been wrestling with a few new sprites. Do I have to place the images in the wad, or can I include them in a directory within a .pk3? I tried searching for this info, and have failed to find it. I tried creating a /things directory, and a decorate lump, but I'm not getting my sprite in-game?

 

actor Ktree01 10242
{
height 256
radius 32
+SOLID
states
{
Spawn:
KTRE A -1
}
}

 

 

Share this post


Link to post

Sprites must be placed in the sprites namespace, which in a pk3 is the /sprites/ folder.

https://zdoom.org/wiki/Namespace

 

So your sprite should be /Sprites/KTREA0.png or perhaps it can be /Sprites/Misc/KTREA0.png, etc. You can use subdirectories to sort your sprites, but the top-level directory in the archive must be /Sprites/.

Share this post


Link to post

 

3 hours ago, Gez said:

Sprites must be placed in the sprites namespace, which in a pk3 is the /sprites/ folder.

https://zdoom.org/wiki/Namespace

 

So your sprite should be /Sprites/KTREA0.png or perhaps it can be /Sprites/Misc/KTREA0.png, etc. You can use subdirectories to sort your sprites, but the top-level directory in the archive must be /Sprites/.

 

Thank you!

Share this post


Link to post

Well, that got it into the game, but as soon as I run the map, the tree falls into the ground, completely out of sight?

Share this post


Link to post

Did you set appropriate offsets on the tree sprite? The offsets should indicate which pixel will be at the base of the actor's projection, that it to say, the bottom center. If it's still [0, 0], that will make the entire sprite be under the floor and to the right. Typically, the X offset should be half the sprite's width and the Y offset should be the sprite's height.

Share this post


Link to post

 

On 8/6/2018 at 2:44 AM, Gez said:

Did you set appropriate offsets on the tree sprite? The offsets should indicate which pixel will be at the base of the actor's projection, that it to say, the bottom center. If it's still [0, 0], that will make the entire sprite be under the floor and to the right. Typically, the X offset should be half the sprite's width and the Y offset should be the sprite's height.

 

 

Wow...I'm such a newb. For the life of me, I cannot even find where to place that info.

 

This is what I have in decorate :

 

actor Ktree01 10242
{
height 256
radius 32
+SOLID
states
{
Spawn:
KTRE A -1
}
}

 

Do the offsets go here?

Share this post


Link to post

Offsets go in the sprite itself, you will need to edit it in SLADE 3. Only Doom-format graphics and PNG images can have offsets.

 

Here's an illustration using an imp sprite. First, the normal imp sprite:

QpKhXnl.png

The horizontal line represents the bottom of the actor and should therefore be the ground for a floor-bound sprite. (For perspective, the imp sinks a bit into the floor, but this doesn't work right with OpenGL. GZDoom has some settings to fudge offsets a bit to avoid having bits of sprites cut off.) The vertical line represents the center of the actor.

Now what happens if the sprite had no offsets? It'd look like that:

RPXzhES.png

The entire sprite gets stuck below the floor, and shifted to the right.

Share this post


Link to post

Oh wow, I completely forgot that step! It's been way too long. Thanks again.

 

I suppose I have to assemble my .pk3 before I can load it in slade? I'm currently working from a directory tree, because I'm constantly adding and editing various items.

Share this post


Link to post

SLADE can actually open directories. Though you'll probably have to save after applying your change to the image and then close the directory from within SLADE to make it easier to make other changes to files from other apps, to avoid situations where you have a conflict between a change made within SLADE and a change made outside of it.

Share this post


Link to post

Got it working, thanks again for the help.

 

How heavy do models weigh on performance? I'm contemplating tree models rather than sprites....maybe some other static models as well.

Share this post


Link to post

It's entirely hardware dependent. On any semi-decent graphics card models shouldn't make any difference at all. Of course, if you try to run the map on some ancient Intel clunker chipset from 10 years ago, things will look different

Share this post


Link to post

That also largely depends on the models, of course. A tree model from Hexen II would be largely equivalent to a sprite as far as performances go; but on the other hand, the Blade of Agony mod developers got angrily yelled at for putting a high-poly, high-res textured tree model in a foggy skybox (where the increased visual quality was unnoticeable by the player, contrarily to the impact on performances).

Share this post


Link to post

One other thing to consider is models combined with dynamic lights can add up to a genuine impact. Models have their lights calculated on a per pixel basis, which looks amazing, but too many lights and models in the same area tends to slow things down.

 

However, IMO don't worry too much about some hypothetical FPS drop at the moment: if you're not seeing an FPS drop, you're not going to be able to account for someone else's machine that might. Just create what you want that runs well on your rig, and then worry about any optimizations needed down the line when you get external testers to try your map. 

Share this post


Link to post

Good points all. I'll start tinkering with some low-ish polycount trees, and see how it looks. I know better than to start using 10k poly models. Also, there wont be any light ents in the same areas as the trees, I'm mainly using the lights indoors. The outdoor "terrain" area is almost entirely sector lighting. I would love to have a "sun" ent, something that would use dynamic lighting on a grand scale. That would make tree models look really cool, as they would cast shadows.

 

The reason I started thinking models is, I took some photos of trees, and made sprites out of them. The high quality photos as sprites just looks like total shit in-game, unless I shrink them down to normal sprite sizes...but then whats the point?

 

I might make some other things for decoration, but that depends on if I see any slowdowns. My system is far from high end. I have a 4gb gtx960.

Share this post


Link to post
1 hour ago, Bauul said:

One other thing to consider is models combined with dynamic lights can add up to a genuine impact. Models have their lights calculated on a per pixel basis, which looks amazing, but too many lights and models in the same area tends to slow things down.

 

Although on any graphics card that's even remotely suitable for gaming this shouldn't be an issue because compared to what modern games calculate per screen pixel this is still peanuts.

11 minutes ago, kdoom said:

My system is far from high end. I have a 4gb gtx960

 

Careful! Although that card cannot be considered high end, it is still a lot better what many Doomers may use. Intel integrated chipsets and older hardware are quite common. That Geforce 960 is probably 4x faster than what you should be aiming at reasonably, e.g. a Geforce GT650.

But don't worry. I have such a card and can run a mod like GeneTech, which uses models exclusively, without any problems.

Share this post


Link to post
8 minutes ago, Jerry.C said:

Although on any graphics card that's even remotely suitable for gaming this shouldn't be an issue

 

Remember GZDoom has none of the modern efficiency methods contemporary engines do. The first version of this map plunged my GTX 1060 from a usual 200 fps it gets on GZDoom to less than 30, due to being over the top with dyn lights, linedefs and models. I had to carefully scale it back to get to more acceptable frame rates.

 

But, conversely, it's not worth worrying about until it's worth worrying about. You might pour all the detail you like into your map and never see anything like frame rate drops like that. So this isn't a call for you to limit effects or anything, just talking about my experiences.

 

I've seen the perception sometimes that because GZDoom is based on an old engine it should therefore run super fast, when actually the opposite is true: because it's based on such an old engine, some visual effects are much more taxing than they would be in a modern engine.

Share this post


Link to post
7 hours ago, Bauul said:

I've seen the perception sometimes that because GZDoom is based on an old engine it should therefore run super fast, when actually the opposite is true: because it's based on such an old engine, some visual effects are much more taxing than they would be in a modern engine.

 

You are of course correct, but models are one of the few things where this does not apply. They can easily be put into data structures that are handled well by modern hardware. From a technical side a model is just a mesh of triangles which all use the same texture and the same lighting settings so they get put into one vertex buffer and rendered with one draw call. In terms of raw triangles, you can render a lot more models than linedefs before things get slow.

 

I guess it would be different if GZDoom had support for bone models.

Share this post


Link to post

Ok, I finally got back into this tree model stuff. I'm sad to say I have an issue that I think isn't fixable. I have built a crude tree model for testing, mainly because I dont know the rendering limits and quirks of GZDoom and models. I have a single skin, half of it is for the solid trunk and limbs, the other half is for the trans portions with leaves on it. GZDoom does render both sides of the trans triangles, but it has an odd flickering in-game....very ugly. it appears if the player can see both sides of the trans portion of the model, it'll start flashing as if the engine doesn't know what amount of lighting to use. bright/dark/bright, etc. I would be very happy if anyone has a workaround for this. I've used this same method to build tree models for other engines, and never saw this before, so I'm lost now. I have a feeling it's caused by the trans portions overlapping. If this is the cause, then I'll scrap this idea, because I dont want to try to build every leaf from triangles. That would be way too expensive on the polycount, in order to get the tree looking even half-ass correct. If I can get this little ( big? ) issue fixed, then I think I can make some nice trees for around 400-500 tris each. Of course when I'm done with this map, everything I have for resources will be free for all to use.

 

This is a screenie of my "test" model. This is a basic method used in almost every game there is, so I hope someone knows a way to make it work in GZDoom!

 

 

 

Edited by kdoom

Share this post


Link to post

Can you post your model here? I'm no model expert but someone might be able to work out what's going on.

 

Tree models with transparent textures can work absolutely fine in GZDoom. I have a whole bunch in my current map and no flickering issues.

 

QSMUK0i.jpg

 

That said, they all use a single image for the skin, not two like you're using. Maybe that's the issue?

Share this post


Link to post

Interesting, I'm fairly certain those trees came from Sauerbraten in your screenie. If thats so, I made those trees many years ago, exactly how I just made this little test model. The only difference is, I think I made those old ones for Sauerbraten as .md2? Not sure about that.

 

I did not mark the trans portions as 2 sided in blender. I doubt that has anything to do with this flickering behavior though. Also, this test does have the whole skin in one file, it's not split up. I could do that if it would work better, I just thought this would keep it simple.

tree01.zip

Share this post


Link to post

I figured out that, just like in the Sauerbraten trees I made many years back, GZDoom doesn't like it if I have intersecting tris that have a trans skin. I can work with this. I'll have to add a few more tris to the count to make them look good, but they should still be well within acceptable range.

 

I'm tempted to just use my old Sauerbraten trees though. Thoughts?

Share this post


Link to post

These old Sauerbraten trees do look ok, but I might make a new skin for them.

 

 

 

Edited by kdoom

Share this post


Link to post

Was just experimenting with dynamic lights, and I see that these tree models do not cast shadows. That kind of sucks. I'm sure it is expensive as all hell on the GPU, but I placed one huge light, just to see how it would look. It ran just fine, but didn't give the shadows I was hoping for.

Share this post


Link to post

Seems the tree models and visual mode dont get along. Since I added the trees, DB crashes when I invoke visual mode.

Share this post


Link to post

I just want to say I'm sorry for not posting for so long. I am doing well, started life over with an amazing woman. My life as a gamer is over for now. I might return at some point in the future but do not hold your breath. I lost everything i once had....home and all belongings including my PC that had all my work and work in progress. The doom community will always hold a place in my heart. Those that were around when i was in my heyday, I wish you all well. Those that carry on the old school gaming, I am proud of you. Keep old doom alive, it is the birth of almost everything that exists, and should always exist for future gamers to see. Thank you all for your encouragement over the years. I'm to damn old now to keep this up, so it's up to the youngsters. Goodbye old friends. Do not feel sad or worry about me.

Share this post


Link to post

Yep I remember you sir, you were one of the few actually publishing wads that utilized boom/zdoom features, in an age when methods and documentation were almost nonexistent, and when everyone else was joining megawad teams for zdoom projects that would never be finished.

 

Perhaps you have that reputation as an envelope pusher, or you perceive yourself that way, and I think perhaps it is a trap because the amount of things to worry about in a source port mod, just explodes in complexity.

 

Join me and many others; the last few years has seen a major resurgence of vanilla mapping. I mean I PLAY zdoom and crazy mods plenty, but when it comes to MAPPING, it's so much easier to stick to vanilla or boom limitations so as to avoid Hurt Locker's "choice paralysis".

 

Sorry to hear you lost everything, but I'm going to disregard your goodbye, and will give you a 1 year allowance to get a new rig operational and posting screenshots again...!

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×