Aller au contenu

Photo

A coupel of question in the matter of doors


  • Veuillez vous connecter pour répondre
37 réponses à ce sujet

#1
s e n

s e n
  • Members
  • 408 messages
I am cooking new doors for the Terria tileset, and after a bit of thinking I decided do make them as generic ones, despite the fact they dont are standard nwn 3x2 dimensions, but scaled to the models, something like 1x2.25, slightly larger and higher than the halforc male model (probably the phat pheno of the halforc will have some probs in stepping past the door :P, but thats it!). Also, I made the animation so open close 1 and 2 are the same. they open always towards the exterior. Now, my questions:
1. in genericdoors.2da there is a VisibleModel column. what is that about?
2. I managed to remove the blue lighting of the transition that comes once the door is open (its controlled by the sam mesh of the door model) but I dunno how to cut the blue highlight of the door it self, that comes when you hover on it be it opened or closed... is it possible to remove it?

#2
Master Jax

Master Jax
  • Members
  • 352 messages
I would actually like to see a re-done model for the original doors. They are just not proportionate. Lower, smaller, locks and handles would do a lot for realism.

#3
Bannor Bloodfist

Bannor Bloodfist
  • Members
  • 947 messages
You really can't go much smaller than the original Bioware 3x2 size. Character size alone is not all that has to be considered. The perspace for any creature is typically quite a bit larger than the actual creature itself.

As to resizing generic doors, that won't work unless you actually feel like editing nearly every tileset out there. Each doorway would have to be adjusted as well. HUGE amount of work involved with that.

#4
s e n

s e n
  • Members
  • 408 messages
Perspace is a **** hehe. not an issue here since those are all transitioning doors but for passage doors like the most part of interior tilesets thats real thing to be considered (made a test with half orc, it doesnt walk past 1 meter large doors. the human model does. but, solution should be slightly adjust the settings of the perspace in the appearances 2da. there may come some mesh collision, but its all designer choice.

fact is, for interiors like dungeons, caves and other tilesets planned to be the theater of battles with monsters, 2 meters wide doors is a necessity. i think the 3x2 doors are very (VERY) ugly but thats it, it is not possible to edit each single tile made since now to fit new scaled dimensions, like Bannor said it is a work of gargantuan size, and really not worth. what is possible, I think, is to study the problem and project new generic doors for new interior tilesets to match world scale.

from my perspective this means deciding a generic dimension for single generic doors (basically, the width, I made 1 meter, it may come that making 1.1 or even 1.2 may be wiser to allow a few more critters to be able to step in) and, realise that natural environment need wider generic doors (1.5 maybe), and making multiple sizes of generic doors brings the need to categorize them, i think a tlk edit for names showing in the toolset would be needed, etc etc. so its still a lot of work, but doable if someone plans to make new interiors.

no blue hints?

#5
s e n

s e n
  • Members
  • 408 messages
a small update after little test: perspace of the half orc is 0.3, as is the one of all standard races but hin (0.25). what blocks movement of the halforc is the height value (appearance.2da column). with my doors of 2.25, the 2da height valueof the halforc (2.25) causes block of movement. changing it to 2.10 allows the halforc to step on the passage.

#6
henesua

henesua
  • Members
  • 3 883 messages
why not adjust your door to slightly larger than the halforc? That way your content will work with standard perspace values.

#7
s e n

s e n
  • Members
  • 408 messages
uhm, there is no problem with perspace of the halforc. the height problem comes from obscuring face of the walkmesh set at 2.25 (you know the fading cube of the buildings behind the doors), something done with transitioning doors and not passage ones, which usually have their walkmesh obscured just in vertical. of course there is not much room, but thats the compromise, and if I ever do a new interior, I will use those door dimensions for generic doors.

#8
NWN_baba yaga

NWN_baba yaga
  • Members
  • 1 232 messages
My castle stone interior and my latest city tileset both have realistic sizes for doors... around 1*2,3m and I havent had any issues with them so far. With realistic i mean when you take the boundaries of a human as the base...

Modifié par NWN_baba yaga, 16 octobre 2012 - 02:00 .


#9
henesua

henesua
  • Members
  • 3 883 messages
Sen, sorry that I mispoke, but the point is that if you make the doors just a little bit larger, no one else has to adjust their appearance.2da just to use your doors/tileset.

#10
s e n

s e n
  • Members
  • 408 messages
Ehehehe Henesua what I mean is that for standard races 1 meter wide doors do not cause issues, unless you put horizontal obscuring meshes under the height of let's say 225+15 centimeters. if you dont use horizontal obscuring faces in the wok, and no one really does unless you want camera blocking controlled by woks, there shouldnt be any sort of issue for standard races.

Baba: its good if we standardize the doors, mines are 1x2.25 if yours are 1x2,3 there is little to do for me to match them, just tell meh!

#11
henesua

henesua
  • Members
  • 3 883 messages
Sorry, Sen. I guess I'm not following you well. Anyway, carry on.

#12
Bannor Bloodfist

Bannor Bloodfist
  • Members
  • 947 messages

s e n wrote...
<snipped>

no blue hints?


Oooppsss.... sorry, forgot to say that;

I have no real idea, other than to say that some of the door activation bit is hard coded into the game.  I vaguely remember requesting a change on that from BIoware, back during WCoC dev days when we still had Bioware's ear.  There was a HUGE list of requested changes that folks wanted though, and as well all know, only so many were addressed.

Been a while, but I think even a hidden door will still give a blue rectangle when you pass your mouse over it?  Will show up when you hit tab in game etc?  As I said, it has been a LONG time since I even considered making door changes other than tileset specific ones, and even then there is a limit to how many you can assign per tileset I believe, but I am likely wrong on that, someone else would have to clarify it for us.

If anyone still has any contact information for OldMansBeard, he would be the wizard with the answers.  Although, I do believe that he has put NWN on far back burner, likely turned off completely, since he is working with Skyrim development now, doing scripting again, which is his strong suit and most enjoyable for him I believe.

You might possibly be able to get the NWNX folks to take a look at possible solutions for the blue highlighting though.  Bioware just didn't have the resources assigned to NWN long before 1.69, we had to beg, borrow and steal folks to get 1.69 out the door as it was.  Of course, BIoware DID come through for us with 1.69, and we all should honestly thank them for their very major efforts for a game that they no longer recieved any compensation for, regardless of sales.

#13
s e n

s e n
  • Members
  • 408 messages
Well yes, I hope there is some 2da setting to disable the blue hover/tab just like there is for creatures in appearance.2da, been trying to add targetable column to doortypes and genericdoors 2das without success

#14
NWN_baba yaga

NWN_baba yaga
  • Members
  • 1 232 messages
@sen
i´m checking my door sizes again just to be sure. ok, the arched default door!

wide:1
height:2,02 (to where the arch starts) + 0,69 (center of the top arch) damn did i f***** it up a bit. But i cant change that anymore... way to many doorframes i would have to redo. But i think we´re on the same goal:) Are your doors rectangle shaped? If yes i will go with your size then!

Well let me rethink: I´m sure i can get the generic archdoor to 1*2m in rectangle and add 0,7m for the arch. Sounds good?

So,
arched    door  = 1*2m/2,7m
genedric door = 1*2,25m

Modifié par NWN_baba yaga, 16 octobre 2012 - 06:51 .


#15
s e n

s e n
  • Members
  • 408 messages
sounds great, its the same size for the generic door, so can safely mix em! if you send me the geometry of a tile with the arched door I will use it for mines as well

#16
Rolo Kipp

Rolo Kipp
  • Members
  • 2 791 messages
<not feeling quite...>

Bannor Bloodfist wrote...
<snipped>
Been a while, but I think even a hidden door will still give a blue rectangle when you pass your mouse over it?  Will show up when you hit tab in game etc?  As I said, it has been a LONG time since I even considered making door changes other than tileset specific ones, and even then there is a limit to how many you can assign per tileset I believe, but I am likely wrong on that, someone else would have to clarify it for us...

From the TileSetConstruction pdf (by, I think, Rob Bartel):

Next, the object called “sam”. After making such an effort to have every object in the max file have a different name, here is the only object that got through. And if that wasn’t bad enough, it was called “sam”. Please don’t ask me why. What does it do? It’s quite simply the object that you click on when the door is an area transition. In the game, you can cursor over a door, and it will show a blue polygon (from both directions). This is “sam”. In order for sam to work, it will also need an animation to reference it…

Later on it goes to say that the color and even the "animation" of the SAM is not set in stone...

The first 7 should be obvious. “trans” concerns the sam object. The way we do it is have a blue self-illumination on the aurapoly for that object. For most animations the poly is at 0.0 alpha (transparent), but for the two frames of the “trans“ anim, the alpha changes to 0.25.

I immediately envisioned whirling red vortexes on certain portals...

<...so blue>

Modifié par Rolo Kipp, 16 octobre 2012 - 11:24 .


#17
Bannor Bloodfist

Bannor Bloodfist
  • Members
  • 947 messages
Ahh, ok, I remember placing "sam" objects, or rather seeing them in tiles which have doors, and being told that they were required. NWmax I think will auto-create that object for you, or maybe it is in Veltools... in either case, I never knew that we could modify it, only that it had to be such-n-such size and located at doorway bottom center.

So, if we investigate a normal tile with a common activatable door setting, we could possibly change the color? Maybe even just eliminate the "sam" object altogether to eliminate the glow effect? I wonder if it is required to exist so that the door WILL work?

#18
Michael DarkAngel

Michael DarkAngel
  • Members
  • 387 messages
I'll go out on a limb and say it's hard-coded.  Evidenced by the following:

Posted Image
Click for full-size image


You can see the self-illumination mirrors the shape of the gate, however the "sam" mesh of the model looks nothing like that.  Not only that, but I did attempt to change the self-illumination color to something more orange-ish.

Let's keep trying to prove me wrong though.  :)

Posted Image
  MDA

#19
Bannor Bloodfist

Bannor Bloodfist
  • Members
  • 947 messages
Yeah, I thought we had tried multiple things with that in the past over in CTP development times... Especially when OMB was around and creating the CTP_GenericDoors files. As I mentioned earlier, I thought it was a hardcoded thing, but the quotes from Rolo made me question my memory a bit... I AM getting older each day and the memory on my system board is dusty, crusty, and missing a few bits here and there.

#20
NWN_baba yaga

NWN_baba yaga
  • Members
  • 1 232 messages
@sen will sent you later this day a yousentit link;)

#21
s e n

s e n
  • Members
  • 408 messages
the sam is the plane that defines the transition: it glows on hover or tab just like the blue door glow, but it is not the blue glow im speaking, they are two separate things. the sam is activated when the door is open, otherwise is completely invisible. it can be coloured, it just "activates" when the door is opened

#22
OldTimeRadio

OldTimeRadio
  • Members
  • 1 400 messages
Just chiming in to support S E N's clarifications about the SAM.

Also, a few other tidbits from testing:
SAM:
* All that need be changed on the SAM to change the color is to set the Self-Illumination to the color of your choice

Blue highlight aura:
* AFAIK so far, no way to change the color of the blue highlight aura via modeling

* All geometry attached to model base will be revealed in blue highlight aura, regardless of whether its Aurora Trimesh modifier is set to render or shadow...or not.  Because of this, non-visible geometry can be made to show up in the blue highlight aura.  The blue highlight aura is very distorted but one might be able to include something interesting in it.

* Visible geometry can be made to NOT show up as part of the blue highlight aura by turning it into "fake" (i.e. 1 bone) skin mesh.  The settings I used were adding one bone, in this case a parent object.  The mesh need not be attached directly to the Aurora base like a regular skin mesh.  In fact, for this to prevent highlighting it may be required that the skin mesh isn't.  All we're really doing is kicking it over into a different rendering pipeline which isn't picked up by the blue highlight aura code.  After all a body part, for instance, executes the same transforms on its mesh that a 1 bone skin mesh does.  There may be more than one way to do this, but skin seemed the least intrusive.  BTW, it doesn't appear that any weight settings on the Advanced Skin Mesh modifier rollout need to be tweaked.  Even with all geometry set like this there still may be some base blue glow that's applied by default and can't be removed.

That's it so far, anyway.

@Rolo Kipp - It looks like your portal graphics might be do-able without too much fuss but thinking about it this morning, it might be easier to use a placeable with a regular transition to achieve the same effect- without having to make a new door.  I haven't thought this through entirely though.

Modifié par OldTimeRadio, 17 octobre 2012 - 02:35 .


#23
Zwerkules

Zwerkules
  • Members
  • 1 324 messages
You can change the 'sam', make it white instead of blue, give it a texture or make it completely invisible, but that other glow that appears when you move the pointer near a door is hardcoded. It is a blue self-illumination of all the visible meshes of a door which is not controlled by any animations or 2da entries, so there's little chance it can be removed.

#24
s e n

s e n
  • Members
  • 408 messages
OTR: that's interesting! But do I have to apply a skinmesh modifier to the visible geometries right? My doors use a single animated pivotting dummy to control all animations, so the geometry itself its already animation-free and linked to that dummy. (note the dummy is slightly offset on the y axis to allow centered pivotting with the door corner, since it uses both open 1 2 animations with the same direction, towards the outside of the building. I had fear that would cause issues with the dummies included in the dwk aurabase but (seems to me) to work fine, and doesnt teleport the char when using the door, be it from in front or from behind the door)

#25
NWN_baba yaga

NWN_baba yaga
  • Members
  • 1 232 messages
@sen
My stone castle tileset interior here in my projects. The shape of the doorframe is what i use for any other archdoors i use for the future too. For the citytileset i used this frame by just copying out the mesh and alligned it for the buildings....