Springheel's Stuff

[OrbWeaver 454]

Re: shadowmeshes: Is it possible to have two shadowmeshes in the model, and sometimes hide one of them with nodraw? So you'd have a body shadowmesh and a helmet shadowmesh, allowing correct shadows for helmeted AI and good "generic head" shadows for non-helmeted AI.

 

A shadow mesh could be reskinned just like any other model, for example the shadowmesh helmet could be made a separate submesh and be skinned with nodraw to disable it.

[Springheel 4402]

It might be easier to have all shadowmeshes with default head-shapes, and then have distinctive helmets/headgear on the head model cast a shadow (or if that's a big performance hit, which I doubt, an extra simplified shadowmesh could be included in the head model). That saves mappers from having to search for the right skin to match the shadow of the head they've chosen.

 

That said, redoing the shadowmesh isn't something I have enough knowledge to do right now, so it'll likely stay the way it is for a while.

[Ishtvan 17]

That does look great. Out of curiosity, is this intended to replace the proguard model? You said the uvmap was easier to work with?

[Springheel 4402]

No, not at all. The proguard model is great. The uvmap is just kind of a pain for making new skins, as the 'crease' on the tunic meets right in the middle of the chest. That makes it very difficult to line up patterns or emblems properly. I've already made two or three skins for the proguard, but I'll probably focus more on making them for the cityguard model in the future.

[Dziarsky 0]

http://www.mindplaces.com/save/belcher2.jpg

 

Dont get me wrong but i dont wanna play with frog ok (mean head)?

Burricks looks more like t-rex dinosaurs, not like a frogs

[Springheel 4402]

I have no idea what that comment means. Are you talking about the texture?

[Dziarsky 0]

Head, head looks like a frog.

We talk about that screen meny times on my polish thief forum and meny people sad that model from that screen looks like mutated frog .

Texture and body looks nice but for me its a frog, not a burrick . That model dont scary me, i am laughing.

 

Look on that pics:

http://imagecache2.allposters.com/images/p...ver-Posters.jpg

http://www.butte.k12.mt.us/webster/student...ce9%20t-rex.jpg

if i find something like this on map i will realy scary.

[Springheel 4402]

Well first, it's not a burrick. Second, I didn't model it. And third, I don't think it looks like a frog at all. But to each their own.

[Dziarsky 0]

Sorry but for me head of that creature looks like frog.

I cant explain that, i see it.

[Baddcog 114]

I gotta say I'm a little confused at why you posted this in Springheel's stuff too Dziarsky. Maybe he did textures (I'm not sure).

 

But anyway, I don't think it looks like a frog anymore than a burrick looks like a t-rex, I mean common, t-rex? 40 foot tall dinosaur of death? Burrick, maybe 6 feet tall with a bad breath problem. Where's the similarity? Maybe the burricks skin looks more like a dinosaur and the belchers skin looks more like a lizard? But a dinosaur is just a large lizard so that's kindof a moot point too.

 

The belcher deffinately has scales, frogs don't. The belcher has mean looking teeth/claws, burricks and frogs don't.

 

Scary??? Burricks were not scary at all, annoying, but not scary. I think the belcher is scarrier just because it has claws and teeth.

 

Anyway, I think there might be path finding probs if the belcher was 40 feet tall.

[Springheel 4402]

I noticed we only have one electric light, which is more for outdoors. Here are two electric lights for wealthier, indoor settings, one pointing down and one up.

 

[PinkDot 0]

Just one thought on that - how many polys does that curved arm have? If we want to go for such smooth curves we really should make much simpler collision models for them. It's very expensive in terms of performance to have collision meshes matching exactly visual models. And we don't need them to be such detailed for metal objects. Wooden things has to be more detailed, because of arrows sticking into them (we don't want to see arrows floating in the air), but as arrows break on metal anyway, we can simplify it a lot.

[Springheel 4402]

The curved arm is actually less than 200 polys. The whole lamp is pretty high though...about 900, though only half of that is shadowcasting. It's actually about the same size as the default gaslamp (800) we've been using forever.

 

A simplified collision model would be easy enough though, and sounds like a good plan for any high poly metal object. Do CMs get calculated at map load or does it only save processing if something actually collides with the object?

[Baddcog 114]

I like it, that's deffinately very steampunk.

 

You should probably do collision for the metal AND glass. Wouldn't be much harder at all.

 

I've been kindof rethinking my antenna a bit. Don't know if it'll have any effect on how you do yours or not.

 

I'm actually thinking of getting rid of my v shaped one and only having 1 antenna, reason being is for one my double lamp has one, it looks cool and is different from T2.

The other reason is I was thinking of particles for them. It might be hard to make a particle that will move down the antenna in a v-hsape and not look weird (trying to match size/shape of V)

But I think it would look cool to have a particle pulsing down a single antenna.

[Springheel 4402]

The antennae (spikes) are just the receivers...they don't require any particle effect. We might want to make a particle effect for the 'transmitters'--those tesla-coil-like things, but even that isn't strictly necessary.

 

If you're talking about the glowy balls that were above some of the T2 streetlamps, I have no idea what those were supposed to be. I don't think there's any need to copy them specifically.

[PinkDot 0]

Do CMs get calculated at map load or does it only save processing if something actually collides with the object?

I believe that simpler collision mesh means shorter compiling the map and smaller .cm file (so loading time should be shorter as well). But the main reason is calculating collisions at runtime. After optimizing collision mesh of my galleon, FPS jumped up from 8 to 15 at worst spots. (It went to 20 after optimizing shadows, btw).

When I think of it now - maybe (I don't know - I'm just guessing) engine computes bounding boxes of models first - in that case smaller models wouldn't have that much impact on performance as big ones, but still - plenty of them will have impact on performance for sure, but not at all on the gameplay.

 

It's actually about the same size as the default gaslamp (800) we've been using forever.

I don't think our models were made with proper optimization in mind. Sure, polycount, shadows and collision meshes - we were aware of this. But nobody thinks about drawcalls. I'm only recently after reading some article on this. Basically every shader, model, texture, light etc. etc. causes draw calls, which are very bad for performance. Ideally every model should have one shader assigned, otherwise drawcalls get multiplied by amount of models, shaders, lights and so on... It's just easy get it out of control.

But at the same time I can't see any good way of managing that in such a project like this mod - most of us don't have game developing experience, everyone here is just a volunteer, doing something from time to time...

[SneaksieDave 39]

I don't think our models were made with proper optimization in mind.

Quoted for truth. That's another place where we could use some guidelines or conventions. I'm basically a newb at modeling, having only made a few simplistic things, but even the bell only has around 500 polys, and there's pretty much no risk of there being four bells in one mansion hallway with guards and other decorations. Total 800 polys (1/5 of a character model) on a single lamp is a bit alarming, and I'm sure it's just one of many things. I started documenting the polycounts long ago (in the hopes of opening some eyes, and maybe aiming us toward establishing some limits on things) but that effort became unnecessary when DR started automatically showing poly counts in the viewer. Very few objects have been made with poly budgeting in mind. Who knows how much effect it is overall, but then no scene is like any other, and it's of course better to be able to put more detail into scenes. Our stuff is even more detailed than Doom3's. We may find out we've got way too much detail in many objects, and only by the time there are far too many to change.

 

We should probably discuss this apart from SH's thread, but it does need discussing.

[Springheel 4402]

I've created a couple dandelion models. The first (the two on the left) is only 266 polys each, of which only 106 are shadowcasting. The second (the two on the right) are only 48 polys each, and can be mixed in with the highpoly ones (or used at a distance). They'll be on SVN shortly.

 

I'll probably do a less lush looking texture for them as well.

 

 

Basically every shader, model, texture, light etc. etc. causes draw calls, which are very bad for performance. Ideally every model should have one shader assigned, otherwise drawcalls get multiplied by amount of models, shaders, lights and so on.

 

I missed this the first time around. I did some tests to see whether multiple shaders had an impact on performance, and they did not (comparing models with 10 different shaders to identical ones with 1). So if it has any effect, it's negligible.

[Baddcog 114]

Nice dandelions! I'd like to see a variation with a puff ball to. Why is the poly count so high though? The low poly ones look good enough to me for what they are. Seems like all the polys are in the stems.

[Springheel 4402]

The low poly one just has a square with a transparent texture for the leaves, so if you look at it on an angle it looks terrible. The higher poly one (I don't think 266 polys is a big deal, especially since less than half are shadowcasting) has separate leaves. Mappers have a choice this way. If the weeds aren't going to be particularly noticeable, then the lowpoly one is fine. If they are, then the other is available.

 

[Tels 268]

The low poly one just has a square with a transparent texture for the leaves, so if you look at it on an angle it looks terrible. The higher poly one (I don't think 266 polys is a big deal, especially since less than half are shadowcasting) has separate leaves.

 

 

It might be much better to do a combination of these two like so:

 

* a quad with some grass, some leaves and soft-shadows painted on

* a few, non-shadow-casting leaves above (to give a 3D effect)

 

Right now, the simpler one looks almost better, as the harsh unnatural shadows from the more complex one ruin the detailed leaves for me.

[SneaksieDave 39]

Haha, these are my nemesis! They look great. I sure spend enough time all summer and fall ripping these out of the ground. For one simple poly saver (might not help much, but a little), the stems could be 4 or even 3 sided prisms.

[sparhawk 17]

I sure spend enough time all summer and fall ripping these out of the ground.

 

Yeah, me too! And they keep coming back...

 

Maybe we should put a lot of them into a garden, and the objective of the player would be to remove at least 80% of them, and everytime the player ripped out ten, one or two are growing back.

[jdude 18]

lol!

 

Very nice! I can wait to put these pests in my maps

[Springheel 4402]

A few more new things for the release map: a simple peasant chair and some fruit.