HomeUser Control Panel (unavailable in archive)ForumsTutorialsArt GalleryResourcesMaps

Doodads visual priority?

01-13-2012, 03:57 PM#1
MasterofSickness
Hi!

Didnt know where to start the thread: in Terrain or Animation or neither,
so I decided to put it here.

I have the following prob:
Click image for larger version

Name:	Waterfall-_VS_WaterSurface-Doodad.png
Views:	35
Size:	655.0 KB
ID:	50741
BTW: How can I make the attachment picture appear at full size??

I'm using:
1) WaterfallFX.mdx ( from Buster ) [_WC3C-Link, #7_] [_HIVE-Link_]
2) WaterPlane.mdx ( from iNfraNe ) [_WC3C-Link_]

Now,
do I have to edit the mdls or change sth in the ObjectEditor,
to make the Waterfall appear over the WaterSurface and not vice versa like in the picture above?



Edit (after cohadars 2nd post), to clear things up, again:
Quote:
...do I have to edit the mdls or change s[ome]th[ing] in the ObjectEditor,
to make the Waterfall [DOODAD] appear over the WaterSurface [DOODAD] and not...
Attached Images
File type: pngWaterfall-_VS_WaterSurface-Doodad.png (655.0 KB)
01-13-2012, 04:08 PM#2
cohadar
I think this is solved by using a water doodad.
01-13-2012, 04:21 PM#3
MasterofSickness
so you are talking about the field "category" (RawData-FieldName)?

I changed the WaterSurface's category to Buildings, but didn't change anything!
Or do I have to restart?
Would be kind of you to give a little bit more of details cohadar...
thx so far!

PS:
Quote:
BTW: How can I make the attachment picture appear at full size??
01-13-2012, 04:33 PM#4
cohadar
Art - Floats: Determines if the doodad goes under water or stays above when you place it on water.


If that does not work download UTM and look for custom water doodad there.
01-14-2012, 04:08 AM#5
Kino
Quote:
If that does not work download UTM and look for custom water doodad there.

Im pretty sure that is the water doodad in the screenshot.

Anyway, I think the problem is due to particle effects (the waterfall foam) being overided by "hard texture" effects. (the water doodad)
01-14-2012, 11:02 AM#6
MasterofSickness
Ah, took me a while to figure it out...
UTM stands for Ultimate Terraining Map!
Yes, I'm probably one of the fews who didnt know it, so its even better that you gave me a hint, thx cohadar!
Nevertheless this pack already includes the WaterPlane I have, like it's stated here:
Quote:
More importantly has 7 standard Blizzard water tiles and iNfraNe's water model, all very useful.

So, a 3rd time,
i already use 2 doodads: 1 for the waterfall and 1 for the water!
Seems to me that changing...
Quote:
Art - Floats: Determines if the doodad goes under water or stays above when you place it on water.
...will affect nothing in my case.

So, I have to change the mdl from what Kino says?
01-14-2012, 11:18 AM#7
cohadar
Have you tried using Waterfall (2) model from UTM?
01-14-2012, 11:53 AM#8
Anitarf
Try raising the waterfall some more. It seems to me that the centres of the foam particles are below the water surface, so the water gets rendered later. It's also possible that water will get rendered later anyway because it's transparent, although judging by the tFT Illidan model, transparent geosets don't automatically get rendered last (in the case of that model, the wings are actually rendered first, so then the rest of the model that's behind them doesn't get rendered at all due to z-buffer).
01-14-2012, 06:35 PM#9
MasterofSickness
@ cohadar
I downloaded the map in ver 3 and checked that.
Yes, the doodad called "Waterfall (2)" uses the same file, I have: "waterfallfx.mdl".
And there is also the mdl from iNfraNe which I use, the WaterPlane.mdl, it is the doodad called "Water". So these should be the exact same mdls I use...
I tested this problem in the U[ltimate]T[erraining]M[ap] too and the same happens again.
(Deleted attached Screenshot, because the next one in this post will show it better.)

You can see, that the waterfall's half left side looks great, while it is hard to spot it at the right where the WaterPlane is... (yes, of course both doodads).
So, how can I give the waterfall the top layer in matter of visibility?

@ Anitarf
Changing the doodad waterfall's height with CTRL + PIC,UP(?) didn't changed anything :(
Quote:
...water will get rendered later anyway because it's transparent...
So editing the mdl seems to be the only way to change the current behaviour?!
Hmm, then, what should be changed there? Instead of Transparent, Blend or what?
EDIT:
"...doesn't get rendered at all due to z-buffer..."
What is z-buffer?

EDIT (SOLVED!):
Okay, I extracted both mdx-files from the U[ltimate]T[erraining]M[ap] Ver 3 and converted them to mdl-files.
I looked into them and the first thing which struck my eye was an entry under the waterfalls' Materials: "PriorityPlane -1,".
And bullseye! By just removing this line 4 times (there are 4 Material-Entries with it),
the magic was done! After reconverting and importing, you can see a distinct change:
Click image for larger version

Name:	PriorityPlane.png
Views:	21
Size:	1.36 MB
ID:	50744
BTW: How can I make the attachment picture appear at full size???

Except the question in red above, just one left:
Why did the author want it to let it disappear behind other doodads?
There is no logical sense for me where you could need sth like this...
Well, I'm sure he had his reasons!

EDIT (2012_01_21):
Because I still had some visual problems by just deleting the "PriorityPlane -1,"
(at some certain camera-angles the Waterfall became heavily transparent again),
here is another solution!
Instead of deleting the "PriorityPlane -1," ones,
rename them to "PriorityPlane 1," and you will have a Waterfall which covers even more.
Attached Images
File type: pngPriorityPlane.png (1.4 MB)
01-14-2012, 11:04 PM#10
Anitarf
It's difficult to explain as I'm not an expert on this, it's just how I understand the bug I observed on the Illidan model which has also showed up in a game project I'm working on. You can read about z-buffer here. The error occurs when the order in which objects are rendered is incorrect. If a triangle that is closer to the camera is rendered first, any triangles hidden behind it won't get rendered. Normally, this saves rendering time so it's good to sort triangles so that ones nearest to the camera get rendered first, but that is not the case for transparent triangles: in their case, you need to see what's behind them, so you need to make sure they are rendered last and that transparent triangles further away are rendered before those closer to the camera (of course, if two such triangles intersect, you won't be able to render them correctly at all).

I'm not sure how and if this applies to your error, but judging by how the problem was fixed I'm guessing it was a rendering order issue.