Request: Real Working Candle

[PinkDot]

I get the "cannot load collision model" error for candle_holder.lwo. How many faces does the CM that you put in have? It should conform to the faces/edges/verts limits outlined in this thread: http://forums.thedarkmod.com/index.php?showtopic=3968

Only 16 polygons?!? Well, that's not good news... I'll change it cause it has more...

But to make sure - we're talking about polygons - not triangle faces, so that means it can have more triangles than polygons, can't it?

 

The candle itself loads okay, but I have some comments on it:

1. It has no bottom, which is okay for this particular application, but if people wanted to also use that model for a free-standing candle that can get knocked around, which is pretty likely, it should have a bottom.

OK, I'll fix this as well.

 

 

2. It seems to have that smoothing problem we've seen with other ASE models in the past. Not sure what you modeling guys usually do about this:

I have mentioned it before. That's the result of exporting through Deep Exploration probably (although DE displays it correctly - it just looks wrong in Doom 3). I have no idea why... I'll try to get some version of Lightwave to convert models properly. (I work in 3dsmax)

[Ishtvan]

Only 16 polygons?!? Well, that's not good news... I'll change it cause it has more...

But to make sure - we're talking about polygons - not triangle faces, so that means it can have more triangles than polygons, can't it?

I don't know, just copied that from the D3 documentation. I'm guessing that what it means, but not sure.

[Domarius]

In my experience, when people say polygons, they mean triangles.

 

Otherwise they talk in terms of quads and triangles, when the distinction needs to be made.

[PinkDot]

In my experience, when people say polygons, they mean triangles.

 

Otherwise they talk in terms of quads and triangles, when the distinction needs to be made.

Simple cube is 12 triangles... So what shape could I make with another 4 triangles...? Hmm... I must check it - it looks impossible to make anything a bit complicated with 16 triangles... (not even L shape...)

 

As far as I know, polygon means any flat shape (f.e. in 3ds max) or any convex flat shape (f.e. in Dromed).

[OrbWeaver]

Simple cube is 12 triangles... So what shape could I make with another 4 triangles...? Hmm... I must check it - it looks impossible to make anything a bit complicated with 16 triangles... (not even L shape...)

 

As far as I know, polygon means any flat shape (f.e. in 3ds max) or any convex flat shape (f.e. in Dromed).

 

I guess it might allow quads, but it's probably triangles. It certainly won't be n-gons (five-sided or more).

[Ishtvan]

I think it might be faces and not tris, because I've seen some with fairly complicated shapes but under 16 faces. If you go ingame and use g_showcollisionmodels 1 on various moveables in D3, you'll get some idea of how complicated it can get. Stuff like the IV stand in test_water looks pretty complex.

[PinkDot]

I was playing a bit with collision model (and managed to get my first moveable ) and it looks like the engine counts polygons as tris or quads or maybe even other n-gons as long as they are completely cooplanar. While making collision mesh it's easy to make polygons curved by moving even just one vertex which causes splitting quad polygons into triangles. It's easy to make some boxy collision mesh, but we just have to be careful when we want to make the collision mesh matching the model tighter.

[PinkDot]

Sorry Ishtvan - I completely forgot to update the candle_holder with working collision model... Now it's on CVS.

 

BTW: I'd recommend all modelers making collision models in .ase or .lwo to make collision material transparent (or semi transparent) so the models are visible in Deep Explorer (and other viewers). I think it's not only me who uses this program to convert files and it would make life a bit easier.

[Ishtvan]

No worries, I've had plenty of other stuff to keep me busy as well. Thanks, I'll try it out soon to make the "real working candle." I think we could do it either as a prefab or an attachment.

 

I think a prefab might actually be better in this case, because attachments don't spawn 'till gametime, so if we attached the candle shaft + flame to the holder, we wouldn't be able to see them and change the lighting on the flame etc in the editor. Prefab sounds like the way to go, and I seem to remember that it copies one target correctly, so as long as the scripting part can be done with only one target, it might work without necessitating the mapper putting in the target names each time it's copied.

[Domarius]

it looks like the engine counts polygons as tris or quads or maybe even other n-gons as long as they are completely cooplanar.

Well that's a releif Interesting too...

[Ishtvan]

Resurrecting this again:

 

We've found out that binding code is such that it stops evaluating physics on the bound entity's collision model.

 

Goal: A candle that is two ents bound together, where the candle part frobs to put out the candle (or light it if you frob it with a tinderbox selected in the inventory), and the bottom part / candle holder frobs to pick up the candle.

 

To satisfy all these requirements, we need:

First model: bottom candle holder model, with a CM that extends all the way up to the candle top, even though its model stops at the candle holder.

 

Second model: Candle (that will be bound to it) with a CM that extends outside of the candle holder cm, so that it can be frobbed. (Again due to this glitch/design flaw in binding, the CM won't actually be used for collisions, just for frobbing, so it's okay if it extends out aways).

[PinkDot]

First model: bottom candle holder model, with a CM that extends all the way up to the candle top, even though its model stops at the candle holder.

This was done already, AFAIR.

 

Second model: Candle (that will be bound to it) with a CM that extends outside of the candle holder cm, so that it can be frobbed.

Current candle has CM matching its exact shape - 2 minutes to change it, so expect it soon...

[Ishtvan]

This was done already, AFAIR.

Okay, sorry, I couldn't remember if it was or not.

 

Current candle has CM matching its exact shape - 2 minutes to change it, so expect it soon...

Just to clarify, this should be a separate model from the default candle that's now used, just in case someone wants to place standalone candles with correct collision meshes. I think you've already been updating a separate file, but can't remember for sure.

 

Also, it should only extend out around the sides, not on the top/bottom. Otherwise it would interfere with frobbing the base and might interfere with the top flame getting stim signals.

[PinkDot]

I'm just uploading candle model with modified CM. (candle2.lwo) Does it look right?

Also - I'm not sure about the origin where it should be - at this moment candle and candle holder have the same origin point (at the bottom of candleholder). I just thought it might be easier for you so you don't have to adjust any offset for the candle...

 

[Ishtvan]

Yeah, that looks exactly right, thanks a lot!

 

About the origin: Ordinarily I would say that for such a small object, it doesn't matter if the origin is not in the center, because that problem gets worse the larger an object is. However, in this case we have two things that we want the player to be able to frob distinctly. When the frob trace does not directly hit the object, it creates a "tolerance" bounds and sees what that bounds intersects. If it intersects more than one object, then it picks the best object according to how close the object origins are to the point where the frob trace hit. Therefore, having the origins for two objects that you want to be able to frob separately be exactly in the same place may be a problem.

 

Suppose your frob trace hits the ground right next to the side of the candle. The top part should be frobbed, because you're frobbing nearer to that. However, the frob tolerance bounds originating at that point where the trace hits the ground overlap both the top and the bottom entity of the candle, and because the origins are the same, distance from the frob trace endpoint to the origin is exactly the same for both entities. Which one actually gets frobbed will be unpredictable, determined by the order they happen to be in in an internal list of entities touching the tolerance bounds.

 

In this case, the only reliable way to frob one or the other would be hit it directly in the center of your screen, or look at a point above it and move down to frob the candle, look at point below it and move up to frob the base. That's not really optimum, and it's a problem we can avoid by moving the candle origin, so I think having the candle origin closer to the center of mass of the candle would be better.

[PinkDot]

Thanks for that explanation! I'm changing this now...

[Ishtvan]

I tested it and it was not that bad, although it was noticeably hard to frob the candle holder and not the stick when looking along the ground next to it. If the candle origin could be moved up just one or two grid units, that would be awesome (I don't know if modelers can make changes equivalent to grid units or not...)

 

Some minor nitpicks: It looked like it was slightly off to one side, I think because the candle origin is slightly off to one side in XY.

 

Also, it appeared to have that smoothing problem we sometimes get for round things. I'm posting a screenshot as we speak...

 

[EDIT: Added screenshot]

[PinkDot]

Try it now. I moved the origin two units up and moved the candle in XY so it matches the candleholder.

The smoothing problem is probably UV coordinates problem - it gets screwed up while converting from .lwo do .3ds in Deep Explorer.
Anyway - this candle model could look better, as Spring has mentioned before, so I'll do another texture plus new UV later. I hope it's OK for now for your physics tests.

[Ishtvan]

Try it now. I moved the origin two units up and moved the candle in XY so it matches the candleholder.

 

The smoothing problem is probably UV coordinates problem - it gets screwed up while converting from .lwo do .3ds in Deep Explorer.

Anyway - this candle model could look better, as Spring has mentioned before, so I'll do another texture plus new UV later. I hope it's OK for now for your physics tests.

 

Yeah, that should be fine, thanks a lot! Right now I'm adding some generic code that should help with this and other situations, and will hopefully have a test map in a few hours.

[Ishtvan]

Questions:

Has anyone tried the "real" candle in torchtest.map? I remember announcing it somewhere and talking about it a little, I think maybe Dave tried it, but don't recall other feedback. If this is how we'll want to do all moveable/extinguishable candles, we should probably get this into the toolkit as a prefab soon so that mappers can start using it.

 

Does anyone have time to make a prefab of it if it is up to snuff?

[SneaksieDave]

Real candle? How recent is it up? I played around in that map a lot, but it was months ago. Last I remember, the items in there work really well.

 

Didn't we figure that prefab has problems, and it would get some kind of base definition as a complex object? I can't remember what the problems were. Maybe rotation was one of them.

[Ishtvan]

I thought we decided prefabs were usable? Don't we have some already?

 

Yeah this was months ago, I'm talking specifically about the candle that you can frob the holder of to pick it up and the top part to frob it. I think I set up the code so that it auto-spawns and binds the light portion, so just the candle and base need to be bound together as a prefab.

 

Btw, I noticed the model for this still has the ASE smoothing issue, the othe candles don't have that, so I'm not sure what's different. From what I understand it's a fairly quick fix.

[Ishtvan]

Oh, I guess I didn't auto-spawn the light after all, but here is 3 entities that would allow for a candle with editable light properties as a prefab. The disadvantage of auto-spawning the light is you can't preview how it will light things in the editor. I think that's why it should be part of the prefab. I'm not sure why the brushdef is in there, might be left over from initially making the collision model?

 

// entity 1
{
"classname" "light_candleflame_moving"
"name" "light_candleflame_moving_11"
"origin" "-1 -523 -357"
"bind" "func_static_81"
}
// entity 2
{
"classname" "func_static"
"name" "func_static_81"
"origin" "0 -523 -362"
"model" "models/darkmod/props/lights/extinguishable/candle2.lwo"
"bind" "atdm:moveable_candle_holder_2"
"frobable" "1"
"frob_action_script" "frob_light_holder_ext"
}
// entity 3
{
"classname" "atdm:moveable_candle_holder"
"name" "atdm:moveable_candle_holder_2"
"origin" "0 -523 -374"
// primitive 0
{
brushDef3
{
 ( -1 0 0 -2 ) ( ( 0.125 0 0 ) ( 0 0.125 0 ) ) "_emptyname" 0 0 0
 ( 0 1 0 -13 ) ( ( 0.125 0 0 ) ( 0 0.125 0 ) ) "_emptyname" 0 0 0
 ( 1 0 0 -2 ) ( ( 0.125 0 0 ) ( 0 0.125 0 ) ) "_emptyname" 0 0 0
 ( 0 -1 0 -13 ) ( ( 0.125 0 0 ) ( 0 0.125 0 ) ) "_emptyname" 0 0 0
 ( 0 0 1 -3 ) ( ( 0.125 0 0 ) ( 0 0.125 0 ) ) "_emptyname" 0 0 0
 ( 0 0 -1 -2 ) ( ( 0.125 0 0 ) ( 0 0.125 0 ) ) "_emptyname" 0 0 0
}
}
}

[SneaksieDave]

I can't recall where we left this or what the potential issues were. :-/ Are you saying making a definition up with all parts (assuming that's even possible) wouldn't let it light in the editor? Well that sucks. Is there any way to get entity defs to indicate and load prefabs? Kinda crappy to load any complex object we have like as a prefab.

 

Gah, my friggin SVN problem has me all discombobulated.

[Crispy]

I played around in torchtest and it was pretty freakin' cool. But I can't offer any technical advice I'm afraid... don't know anything about prefabs.