Aller au contenu

Photo

Tile Magic


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

#51
WebShaman

WebShaman
  • Members
  • 913 messages
Awesome sauce! This community never fails to amaze me, even after all these years...

#52
henesua

henesua
  • Members
  • 3 864 messages
Another aspect of tilemagic that we have not gotten into is WOK modification.

See OTR's video and the discussion that followed it.

I am leaning more and more toward using placeables for tilemagic, and then recalled that discussion about PWKs and WOKs. I suspect that sing a placeable in this fashion could allow a PC to walk across a bridge, that can also be walked under. Could be cool eh?

#53
henesua

henesua
  • Members
  • 3 864 messages
Are there issues with using a model with a Tile classification as a Placeable?

I am tempted to include the WOK with each of the tiles I modify and add to placeables.2da

[edit]
It appears to work just fine. I am unable to discern any issue with this.
Posted Image

The monster is standing on a placeable version of a barrows tile which was plopped down in the Fort tileset. I located the placeable in the center of the tile.

More tests to follow.

Modifié par henesua, 22 décembre 2012 - 06:55 .


#54
OldTimeRadio

OldTimeRadio
  • Members
  • 1 400 messages

henesua wrote...

Are there issues with using a model with a Tile classification as a Placeable?

IIRC, Adam Miller once reported there were problems using more than 10-15 placeables set as tile classification.  Only time I've ever heard of any issues though, and things may have changed for the better since then.  As to overlaying a placeable WOK onto of a tile WOK, you might want to make sure that there are no issues with, for instance, dropped objects disappearing.  This may only occur when the placeable's WOK is +/- 10-25cm different than the WOK it's overlaying, but it was something I came across with a placeable WOK tower I made.  There may also be other unintended consequences.

I like the idea of doing away with visible geometry altogether on a tileset, but each riff on the idea seems to have its own can of worms to deal with.

Modifié par OldTimeRadio, 22 décembre 2012 - 08:00 .


#55
henesua

henesua
  • Members
  • 3 864 messages
After more playtesting...
Posted Image
Note how the footstep type reflects a water material although the placeable tile is dirt. The tileset tile underneath the placeable tile had a walkable pool. The placeable tile mounded up over the pool thus placing the player at a higher elevation.

I have not found any problems related to number of tile placeables. I filled up an 8x8 area (the typical size I use) with these and had no problems with them: 64 placeables each with a Tile designation.

Other findings:
  • placeable must be set to static, for the placeable's WOK to modify the tile's WOK. I suspect that a placeable must be in place when the module is loading as well, but have not tested this yet with dynamically changing placeable tiles.
  • placeable must be oriented in same X and Y coordinates as the center of the tile. For tcovering the bottom left tile this means the placeable must be set at x 5 and y 5. If the placeable overlaps an adjent tile, when a player character enters that tile there is a hiccup, the chracter is jettisoned up in the Z access, appearing to walk in space, then after a moment returns to the tile.
  • placeable's z coordinate can be anything you want, but this looks jarring when it is a visible distance such as 2 units (meters?) above the ground plane of the adjacent tile.
  • many aspects of the tile's WOK are unchanged by the placeable WOK. Footsteps do not change. Obstructions do not change and thus pathfinding does not change. I imagine visibility does not change either.
  • Items seem to rest on the Placeable WOK and on the Tile WOK. I'm not sure how this works. Can a WOK be applied to any mesh? Meaning can you have multiple WOKs per tile model? I was able to place a great sword on the modified ground (the placeable tile), and on an adjacent table which was part of the tile model.

Modifié par henesua, 22 décembre 2012 - 11:11 .


#56
henesua

henesua
  • Members
  • 3 864 messages
Some more screenshots which may be misleading but are interesting.

renderaabb 0 (normal render)
Posted Image

renderaabb 1 (wok render)
Posted Image

When rendering the WOK mesh, only the placeable's WOK is visible.  This may be merely a quirk of the renderaabb command since I have already found that the only aspect of the placeable WOK that takes precedence is the Z height.

Modifié par henesua, 22 décembre 2012 - 10:31 .


#57
henesua

henesua
  • Members
  • 3 864 messages
One major misconception I have been implying, and which I wish to now correct. The WOK file is unnecessary to get the behavior described above.

You do not need to include the WOK file with the MDL for the Z heights to work. I have tried this with a WOK and without and the behavior is the same. I believe the MDL file contains the information for Z Height in the aabb node.

Example:
node aabb Plane05
  parent plctile_dirt01
  position 0.0 0.0 0.01
  orientation 1.0 0.0 0.0 0.0
  wirecolor 0.0 1.0 0.0
  multimaterial 99
    Walkmesh - Dirt 
    Walkmesh - Obscuring
    Walkmesh - Grass
    Walkmesh - Stone
    Walkmesh - Wood
    Walkmesh - Water
    Walkmesh - Nonwalk
    Walkmesh - Transparent
    Walkmesh - Carpet
    Walkmesh - Metal
    Walkmesh - Puddles
    Walkmesh - Swamp
    Walkmesh - Mud
    Walkmesh - Leaves
    Walkmesh - Lava
    Walkmesh - Pit
    Walkmesh - Deep Water
    Walkmesh - Door
    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL
    Walkmesh - Unassigned
  ambient 0.415686 0.384314 0.254902
  diffuse 0.415686 0.384314 0.254902
  specular 0.0 0.0 0.0
  shininess 10.0
  bitmap Walkmesh - Dirt
  verts ..........
........
endnode

Next thing to try is to manipulate that node and see what happens.

#58
henesua

henesua
  • Members
  • 3 864 messages
 I am stumped.

The file pasted below when used as a static placeable does not not render the cursor click when a player clicks within the tile. I can't figure out why. I have not encountered this with any other tile.

#MAXMODEL ASCII
# tdg07_e20_01
filedependency Unknown
newmodel plctile_stone08
setsupermodel plctile_stone08 null
classification TILE
#MAXGEOM ASCII
beginmodelgeom plctile_stone08
node dummy plctile_stone08
parent NULL
endnode
node aabb rectangle998
parent plctile_stone08
position 0 0 0.01
orientation 0 0 0 0
wirecolor 0.521569 0.521569 0.521569
ambient 0.2 0.2 0.2
diffuse 0.8 0.8 0.8
specular 0 0 0
shininess 1
bitmap NULL
verts 4
-5 -5 0
5 -5 0
5 5 0
-5 5 0
faces 2
0 1 2 1 0 0 0 7
3 0 2 1 0 0 0 7
aabb -5 -5 0 5 5 0 -1
-5 -5 0 5 5 0 1
-5 -5 0 5 5 0 0
endnode
node trimesh plane427
parent plctile_stone08
position 0 0 0.01
orientation 0 0 0 0
wirecolor 0.109804 0.34902 0.694118
tilefade 0
scale 1
render 1
Shadow 0
beaming 0
inheritcolor 0
rotatetexture 0
alpha 1.0
transparencyhint 0
selfillumcolor 0.0 0.0 0.0
ambient 1 1 1
Diffuse 1 1 1
Specular 0 0 0
shininess 1
center 0.0 0.0 1.0
bitmap brownwall05
verts 25
-5 -2.5 0
-5 -5 0
-2.5 -2.5 0
-2.5 -5 0
0 -2.5 0
0 -5 0
2.5 -2.5 0
2.5 -5 0
5 -2.5 0
5 -5 0
-5 0 0
-2.5 0 0
0 0 0
2.5 0 0
5 0 0
-5 2.5 0
-2.5 2.5 0
0 2.5 0
2.5 2.5 0
5 2.5 0
-5 5 0
-2.5 5 0
0 5 0
2.5 5 0
5 5 0
faces 32
0 1 2 1 0 1 2 1
3 2 1 1 3 2 1 1
2 3 4 1 2 3 4 1
5 4 3 1 5 4 3 1
4 5 6 1 4 5 6 1
7 6 5 1 7 6 5 1
6 7 8 1 6 7 8 1
9 8 7 1 9 8 7 1
10 0 11 1 10 0 11 1
2 11 0 1 2 11 0 1
11 2 12 1 11 2 12 1
4 12 2 1 4 12 2 1
12 4 13 1 12 4 13 1
6 13 4 1 6 13 4 1
13 6 14 1 13 6 14 1
8 14 6 1 8 14 6 1
15 10 16 1 15 10 16 1
11 16 10 1 11 16 10 1
16 11 17 1 16 11 17 1
12 17 11 1 12 17 11 1
17 12 18 1 17 12 18 1
13 18 12 1 13 18 12 1
18 13 19 1 18 13 19 1
14 19 13 1 14 19 13 1
20 15 21 1 20 15 21 1
16 21 15 1 16 21 15 1
21 16 22 1 21 16 22 1
17 22 16 1 17 22 16 1
22 17 23 1 22 17 23 1
18 23 17 1 18 23 17 1
23 18 24 1 23 18 24 1
19 24 18 1 19 24 18 1
tverts 25
0 0.501953 0
0 0.00195313 0
0.5 0.501953 0
0.5 0.00195313 0
1 0.501953 0
1 0.00195313 0
1.49805 0.501953 0
1.49805 0.00195313 0
1.99805 0.501953 0
1.99805 0.00195313 0
0 1 0
0.5 1 0
1 1 0
1.49805 1 0
1.99805 1 0
0 1.5 0
0.5 1.5 0
1 1.5 0
1.49805 1.5 0
1.99805 1.5 0
0 2 0
0.5 2 0
1 2 0
1.49805 2 0
1.99805 2 0
endnode
endmodelgeom plctile_stone08
donemodel plctile_stone08

#59
henesua

henesua
  • Members
  • 3 864 messages
I figured out the problem with the cursors, and learned one more thing that a placeable tile's aabb mesh influences.

By changing
    faces 2
    0 1 2 1 0 0 0 7
    3 0 2 1 0 0 0 7
to
    faces 2
    0 1 2 1 0 0 0 1
    3 0 2 1 0 0 0 1

i enabled the mesh to register a crosshairs when a PC clicks on it.

And no that is not what I've been doing all day. The answer came to me out of the blue while doing something else. I should try that more often.

Modifié par henesua, 23 décembre 2012 - 06:01 .


#60
henesua

henesua
  • Members
  • 3 864 messages
I just reworked the fog plane from the steam works tileset so that it appears similar to radiation fog on a very cold and yet dry day. That thin fog layer that forms just a few inches above the ground and fades away.

Anyway, I made some adjustments to the emitter so that it inherits color similar to how the mist placeable works, it seems to inherit its color from the area's Ambient light. How does one make it inherit color from the area's fog color?

#61
henesua

henesua
  • Members
  • 3 864 messages
 Another change caused by placeable tiles

Posted Image

The camera is able to pass through the edge although players can not. My question: how do these placeable tiles affect visibility?

#62
Shadooow

Shadooow
  • Members
  • 4 470 messages
placeables hardly could affect visibility, visibility is based on tile and values described in SET file for that tileset - I dont think placeable could alter it so when applying placeables on ground, player walking around will reveal more than 3tiles in advance in all directions no matter there is placeable wall

The only way to solve this is to make a special clean tileset with several tiles which will have walkmesh and visibility set for specific purposes and the tile will appear in toolset as a plane with a letter indicating the walkmesh/visibility node for easy use.

#63
henesua

henesua
  • Members
  • 3 864 messages
More experimentation, this time with a better radiation (low) fog. Its a placeable with 10 emitters. Each emitter is .05 apart in height from the next. and emits one 10x10 fog plane which persists. The effect looks good...
Posted Image

BUT ... why does the entire "tile" light up in the dark?
Posted Image

How do I solve this?

Here's one of the emitter nodes:

node emitter MISTA01
parent plcfx_tile01
position -0.00612812 -0.00764999 0.05
orientation 1.0 1.19209e-007 0.0 -2.38419e-007
wirecolor 1.0 1.0 1.0
update_sel 2
update Single
render_sel 4
render Billboard_to_World_Z
blend_sel 3
Blend Lighten
spawnType 0
xSize 0.0
ySize 0.0
inherit 0
inherit_local 0
inheritvel 0
inherit_part 0
renderorder 0
threshold 0.0
combinetime 0.0
deadspace 0.0
opacity 1.0
colorStart 0.862745 0.862745 1.0
colorEnd 0.862745 0.862745 1.0
alphaStart 0.1
alphaEnd 0.1
sizeStart 10.0
sizeEnd 10.0
sizeStart_y 10.0
sizeEnd_y 10.0
birthrate 1
lifeExp 0.0
mass 0.0
spread 0.0
particleRot 0.0
velocity 0.0
randvel 0.0
bounce_co 0.0
blurlength 10.0
loop 0
bounce 0
m_isTinted 1
splat 0
affectedByWind false
texture plcfx_tile01
twosidedtex 0
xgrid 1
ygrid 1
fps 0
frameStart 0
frameEnd 0
random 0
lightningDelay 0.0
lightningRadius 0.0
lightningSubDiv 0
lightningScale 0.0
blastRadius 0.0
blastLength 0.0
p2p 0
p2p_type Bezier
p2p_sel 1
p2p_bezier2 0.0
p2p_bezier3 0.0
grav 0.0
drag 0.0
endnode

Modifié par henesua, 24 décembre 2012 - 01:55 .


#64
henesua

henesua
  • Members
  • 3 864 messages
Anyone know if it is possible to set an emitter to receive area light but no other kind of light?

Modifié par henesua, 24 décembre 2012 - 02:53 .


#65
Rolo Kipp

Rolo Kipp
  • Members
  • 2 791 messages
<shooting...>

My first thoughts are to play with the blend settings and the inheritance. If the blend or render settings don't help, maybe making the emitter the child of a dummy or non-rendering geometry might.

<...in the dark>

#66
henesua

henesua
  • Members
  • 3 864 messages
I changed
m_isTinted 1
to
m_isTinted 0

and the emitter no longer picks up any light. so it shows up as white mist, rather than inheriting the color of the light.

This may have to do unless I add more emitters in each of the 10 planes, and change the image so that it doesn't read as a square with a cloudy texture.

#67
Shadooow

Shadooow
  • Members
  • 4 470 messages

Zwerkules wrote...

Henesua, this is a very good idea. I always thought it would be nice if turning on animloops could be scripted.

I just developed a functions Get/SetTileAnimLoop in nwnx. The drawback is that this will not get updated without re-entering the area, so I guess this solution still comes handy especially of someone make a special tileset for that matter as I described  few posts above.

#68
OldTimeRadio

OldTimeRadio
  • Members
  • 1 400 messages
I noticed you were talking about a whole tile lighting up.  NWN uses vertex lighting and when a surface is made of very few vertices, the lighting can break down and unrealistic lighting can result.  "Very few" is like...2 triangles.  I'm not sure if that's what you're seeing or not, though.

Modifié par OldTimeRadio, 24 décembre 2012 - 05:33 .


#69
henesua

henesua
  • Members
  • 3 864 messages

OldTimeRadio wrote...

I noticed you were talking about a whole tile lighting up.  NWN uses vertex lighting and when a surface is made of very few vertices, the lighting can break down and unrealistic lighting can result.  "Very few" is like...2 triangles.  I'm not sure if that's what you're seeing or not, though.


I'm confident that I'm seeing something related to that. I suspect that an a billboard of only 2 triangles is what is produced by an emitter. I think the long term solution is to add more and smaller particles for the fog. That way the entire 10x10 area won't light up at once.

#70
henesua

henesua
  • Members
  • 3 864 messages
 I worked on the fog today between the festivities, and I'm disappointed.
Posted Image

Notice how tiled that is. I broke down the 10x10 placeable into 10 layers of 25 emitters, each creating a 2mx2m billboard. The multiple layers creates the foggy blending, and sense of depth. BUT even at 2x2 billboards, the effect is jarring.

At eye level its pretty though.
Posted Image

This particular fog effect will inherit the color of the area lighting and disappears into darkness. Which is achieved with this setting
m_isTinted 1
on the emitter.

I think I'll be going back to 10 emitters each a 10x10 billboard layered one on top of the other, but using the setting
m_isTinted 0

This result creates white fog that will extend into the darkness. But at least it won't look blocky.

#71
henesua

henesua
  • Members
  • 3 864 messages
This is why I want to improve the tilemagic situation...
Posted Image
TNO tileset w/ Project Q's Canyon terrain (by Pstemarie).
Water and fog are produced by tilemagic. The water is made from the animated ocean plane in TNO, and the fog is a reworked placeable which I can't remember the original source of.

With scripts I will be able to simulate tidal action around Duivelseiland in Arnheim. Tilemagic is an important piece of that.

#72
OldTimeRadio

OldTimeRadio
  • Members
  • 1 400 messages
Good idea!  I assume you're keeping the animesh animations in the water?  If you are and you aren't already compiling the model, this model compiler should work for you and it'll save a decent chunk of time when loading a number of models into a scene.