Ungoliant's mapping questions

[Fidcal]

Well it's of use in situations to help with performance where a shadow doesn't matter, eg, on a rooftop you can't reach or pasted onto a skyline etc. In fact I'm using it on the ground in mine without a shadow in a dark area where it's hard to see anyway.

 

The problem with models for fences is they are so inflexible. A fence curves up a hill or stairs and it has no angle plus you usually want a particular length. So it would need a set of lengths and curves for any particular fence like a model railway track set.

[Tels]

Well it's of use in situations to help with performance where a shadow doesn't matter, eg, on a rooftop you can't reach or pasted onto a skyline etc. In fact I'm using it on the ground in mine without a shadow in a dark area where it's hard to see anyway.

 

The problem with models for fences is they are so inflexible. A fence curves up a hill or stairs and it has no angle plus you usually want a particular length. So it would need a set of lengths and curves for any particular fence like a model railway track set.

 

Or we dynamically build the fence from small parts. I think if somebody builds a "one fence-post and a bit of a connect" plus "one fence post plus the end piece", I could string along a fence from these two pieces. Only problem is, how does the mapper say inside DR where the fence should be?

 

Possible solution: Small "virtual fence post" entities. You tell the entity which corner piece it should have, and what fence piece should be connect it to the next fence post. Think of it like AI paths. Once this is build in DR, the code creates the actual fence at map load. This way it can be a model fence. (With LOD if you like).

 

And since the code wouldn't care what fence it actually builds, that could lead to all sort of interesting things.

[ungoliant]

still, I think the point fidcal is trying to make is that on hills or stairs, the fence connectors would have a "step" effect. The posts certainly should go up in steps, but the connecting bits should be smooth and be angled parallel to the curve that the fence is on. I don't see how that could be achieved short of stretching decal textures, but they do not cast shadows.

[Tels]

still, I think the point fidcal is trying to make is that on hills or stairs, the fence connectors would have a "step" effect. The posts certainly should go up in steps, but the connecting bits should be smooth and be angled parallel to the curve that the fence is on. I don't see how that could be achieved short of stretching decal textures, but they do not cast shadows.

 

With three fence-pieces as models, you can easily do this:

 

 

We just need a way to specify in the editor where the fence should run along, and the bit of code that constructs the megamodel from the the individual pieces. The entire fence will then be one model (or several, if you wish, so as to not cross visportals). And et voila, custom made terrain-following fence model.

[ungoliant]

so you are cool with the intersecting pieces being always horizontal? what about on a steep curve, if an intersection piece is very close to the top of the model. The horizontal piece between posts might actually stick out above the head of the lower post if the curve is steep enough.

 

I think i might of written an english-fail there. If that doesn't make sense I can draw a picture.

 

edit: also, your fence idea has already been (mostly) implemented. There is a fence model set up roughly the same way, except of course that DR doesn't dynamically pathfind and place models like railroad tracks between a start/end point. And even if you could, what about spawnargs? maybe you need that fence to be noshadows or suffer huge performance hit. Isn't it true that dynamically spawned entities can't use spawnargs that they don't inherit?

Edited December 2, 2010 by ungoliant

[Tels]

so you are cool with the intersecting pieces being always horizontal? what about on a steep curve, if an intersection piece is very close to the top of the model. The horizontal piece between posts might actually stick out above the head of the lower post if the curve is steep enough.

 

Well, well, you can't sovle every problem at once If the climb is *that* step, either you need to angle the pieces, or do something else. I just wanted to say that it is all (almost all) possible if you design the piece and the code clever enough.

 

I think i might of written an english-fail there. If that doesn't make sense I can draw a picture.

 

I think I know what you mean, but it should be no problem to build a horizontal fence, then angle it to match the ground. (The step-wise fence is actually not more or less complicated).

 

edit: also, your fence idea has already been (mostly) implemented. There is a fence model set up roughly the same way, except of course that DR doesn't dynamically pathfind and place models like railroad tracks between a start/end point. And even if you could, what about spawnargs? maybe you need that fence to be noshadows or suffer huge performance hit. Isn't it true that dynamically spawned entities can't use spawnargs that they don't inherit?

 

Since the entity is *build* dynamically, it can also get any spawnargs you want, you just need to set the on the virtual fence posts and the generator would pass the along.

 

Thinking abit more about this, a "fence builder" would actually be easier than a "tree builder" so one day I might just create it as a proof-of-concept

[ungoliant]

well good sir, lets see your fence generator handle this pathfinding then!

 

[rich_is_bored]

If you're seriously entertaining this idea you might go one step further and implement a mesh modifier system like that used in a modeling package.

 

For example, a cube being duplicated with an array modifier ...

 

http://www.youtube.com/watch?v=G6xaiKK0ViM

 

... or a tire bulging at the base with a lattice modifier ...

 

 

If such a system existed within idTech 4, you'd have a way to scale models.

[Tels]

If you're seriously entertaining this idea you might go one step further and implement a mesh modifier system like that used in a modeling package.

 

For example, a cube being duplicated with an array modifier ...

 

http://www.youtube.com/watch?v=G6xaiKK0ViM

 

... or a tire bulging at the base with a lattice modifier ...

 

 

A "general mesh modifier" is a lot more complicated then just stringing together a few model parts For Ungoliaths example, you'd need at least a "build a warping cylinder tube" code, but the rest is simple "copy&paste" from parts, which is much easier. Plus, whatever system you build, it must be easy to use it inside DR, and that limits it somewhat (unless you want towrite a lot of code for DR, too, which I can't). So I'd definitely would start small, we can always expand it later.

 

If such a system existed within idTech 4, you'd have a way to scale models.

 

We already have such a system - the old "rotation hack", and the new model generator:

 

 

 

The problem is that these both only scale the rendermodel, but not the clipmodel. I do have an idea where one might insert code to do this, but scaling clipmodels is not as easy because their data structure is completely different and I haven't made yet head or tails out of it...

[rich_is_bored]

I bring up the idea because your initial description describes an array modifier pretty well. You have an object, a relative offset, and a number of iterations.

 

I figure the parameters could be clumped together into a space delimited string and stored in a key/value pair. People can punch values into key/value pairs already. A shiny user-friendly widget like the one used for "_color" can be made later if desired as can additional modifiers.

 

At any rate, I'm just offering my thoughts. I don't want to derail the thread.

[ungoliant]

derail permission granted. this subject is cool.

[ungoliant]

I'm using models/darkmod/door_related/mansion_door_02_handle.lwo, but my door was too thick for it, so I used rotate hack. This worked fine, until i converted the model to atdm:mover_door_handle. Now the rotation hack doesn't work in game, but it still shows working in DR. whats up with that?

[Fidcal]

Try making the rotation hack uniform eg, 1.2 0 0 0 1.2 0 0 0 1.2. Also try giving it solid 0. If it still won't work then make a nodraw brush, convert it to a handle entity. Now make your handle a func static and bind it to the brush. Now make it frobable 1 and frob_distance 1. Now give the brush frobbox_size 5 and frob_peer <handle name>.

 

If it works what happens is when you look at the handle you are also looking at the invisible brush handle. Because it has a big frob box it will invisibly highlight not the handle. But because it is frob_peered then the handle will actually light up. What I mean is, the handle won't hilight directly on its own which won't work.

 

I'm sure that's clear as mud but try it.

[ungoliant]

no i get the frob_peer thing, and since nodraw doesn't have that whole parm11 thing in the shader, it shouldn't make highlight the invisble box. keep actual handle model as FS and bind to the 45 degree rotating door handle brush, and hopefully the FS will still accept rotate_hack. don't have time to try it now, i'm going to see Harry Potter 7 with some friends, yay! bbl tonight will try.

[Noisycricket]

Oops, wrong thread...

[ungoliant]

uniform rotation hack values were ineffective. Making it solid 0 ineffective. Last resort solution worked. Although I left out the part about frobbox_size 5 on the no_draw brush handle, seemed unnecessary.

 

Is there really no way to merge separate model's into other entities? once i got done binding all the lockboxes, handles, invisible handles, door knockers, my door now consists of 6 entities. and its a double door, so make that 12. ouch. not a major issue by itself unless repeated for another 100 doors throughout the mission, but still.

[Fidcal]

Hopefully that's a one-off. Most doors don't need all that. I used those handles and left them the normal size but let them penetrate into the door. Most doors won't need a knocker or lockbox. 99% of all my doors are just a door and double handle.

[Bikerdude]

 

I see the work i did on the stairs is holding up well...

[ungoliant]

some changes here and there, but yes, they are holding up well, and thank you for the help. perhaps i should put a big gui overlayed on the wood panel says "b1k3rdude" running up it just to show whos boss?

[ungoliant]

I have returned (for now), with a new widescreen LCD monitor generously donated by family. This coupled with the awesomeness of 1.03 has inspired me to work harder on the FM. And now I have a few questions:

 

1. how exactly does the texture "aassolid" and the func_aas_obstacle entity work? I followed the elevator wiki, but I don't really get whats going on there. I assume its related to allowing AI to use elevators, but I don't get how the elevator is triggering these on or off, or what-have-you. Also I looked at a few other elevators that don't use the aassolid textured brush at all, or bother with setting up the "start_on" spawnargs.

 

2. I'm setting up a sort-of warehouse door that translates 92 units on x and z axis, and rotates 90 degrees on y axis. This is all well and good, except when closing the door from a half-opened state. The rotate speed works properly, but the translations in both directions slow down to take the full amount of time to close as it would from a fully opened state. Can't figure out whats causing this. ideas?

 

3. The specular on the iron fencing decal shown in the screenshot quoted above has gone totally crazy since 1.03, and is almost stark white the whole way across when its lit up. Is this something i should leave alone at defaults due to users having different settings, or is something wrong here with speculars since 1.03?

Here is the specular stage in the shader:

{

blend specularmap

map _white

rgb 0.1

}

[nbohr1more]

Welcome back Ungoliant!

 

Since your using an internal map for the specular I'm not sure that the v1.03 material batch converter will work but you should be able to workout the syntax by comparing to any stock v1.03 asset with specular.

 

You would probably need to point to your specular definition from with the ambient method def:

 

Presuming your specular is:

 

textures/darkmod/specular_ungoliant_rail

{
blend specularmap
map _white
rgb 0.1
} 

 

// TDM Ambient Method Related
{
if (global5 == 1)
blend add
map textures/darkmod/yourname // Diffuse
scale 1, 1
red global2
green global3
blue global4
}
{
if (global5 == 2)
blend add
program ambientEnvironment.vfp
vertexParm 0 1, 1, 1, 1 // UV Scales for Diffuse and Bump
vertexParm 1 1, 1, 1, 1 // (X,Y) UV Scale for specular
vertexParm 2 global2, global3, global4, 1

fragmentMap 0 cubeMap env/gen1
fragmentMap 1 textures/darkmod/yourname_local // Bump
fragmentMap 2 textures/darkmod/yourname // Diffuse
fragmentMap 3 textures/darkmod/specular_ungoliant_rail // specular
}

Edited December 30, 2010 by nbohr1more

[Springheel]

Using _white for specular never gives very good results, and seems to be even worse with 1.03. If it's metal, I'd just select an existing metal specular to use instead.

[Fidcal]

Welcome back ungoliant. Glad to hear you're working on your FM again!

 

1. Pathfinding is pre-compiled on worldspawn when you dmap. aassolid enables pathfinding for that surface but not solid in any other way otherwise no pathfinding would be enabled there. AASobstacle dynamically blocks it when the elevator is absent so the AI do not walk there.

 

2. Dark Mod doors do not allow for both rotation and translation. Instead, make two doors, one translating and one rotating and bind one to the other. Target them both or target one to the other. Note if you target from a door then set trigger_on_close to 1. See the secret door in the writing bureau prefab as an example or there are one or two in Builder's Influence wot I did.

 

3. My guess is that _white is copied to the specular part of the new final stage in that material and is used fully whereas the original specular is reduced to rgb 0.1 (does that really work?) Have you got enhanced set for ambient rendering? Sounds like that material needs fixing.

[nbohr1more]

Reducing a "map _white" with an RGB value is one of the tricks that Rich_is_Bored has been doling out so I presume it works

 

(But within the context of the new Ambient methods... who knows... )

Edited December 30, 2010 by nbohr1more

[Radiatoryang]

Wait, I'm trying to make similar rails for my staircase -- did you do that with patches?

Edited December 31, 2010 by Radiatoryang