Doomworld Forums - Slime trails

Doomworld Forums : Powered by vBulletin version 2.2.5

Doomworld Forums > Classic Doom > Doom Editing > Slime trails

Pages (2): [1] 2 »

Author

All times are GMT. The time now is 12:38.

NaturalTvventy
Member

Posts: 518
Registered: 06-09

My WAD has slime trails galore. It's a big level - over 4000 sectors and rising. I use zdbsp to build the map. Any way I can fix the trails?

Thanks,

NT

02-15-10 08:46 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Subatomic
Junior Member

Posts: 176
Registered: 09-08

This might be of help to you:
http://doomwiki.org/wiki/Slime_trail

02-15-10 14:21 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 6962
Registered: 01-03

What port are you mapping for? If your map is ZDoom exclusive you should use ZDBSP's compressed nodes which don't produce slime trails.

02-15-10 15:52 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

NaturalTvventy
Member

Posts: 518
Registered: 06-09

The map is not exclusively Zdoom, and it has a ton of non-horizontal or vertical lines(I saw from the wiki that this tends to cause slime trails). Any tools that can help me out?

Yaknow one interesting thing to note is that my WAD was slimetrail-free until I switched over to using Doombuilder2. Originally I was using DETH, but once my WAD got too big for that old editor to handle I switched to DB2 and instantly had all these slime trails. I dunno if something happened that both generated all the slime trails and made the WAD too screwy for DETH, or if it was the switch to DB2 that was the cause of the smile trails.

Last edited by NaturalTvventy on 02-15-10 at 16:25

02-15-10 16:16 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

D_GARG
Forum Regular

Posts: 739
Registered: 12-09

Subatomic said:
This might be of help to you:
http://doomwiki.org/wiki/Slime_trail

you can use this to make deep water aswell, look map01 on the mega wad
Alien Vendetta

its usefull, works even for the buggy doom95 engine

02-16-10 07:58 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

esselfortium
Cumulonimbus Antagonistic Posting

Posts: 5152
Registered: 01-02

D_GARG said:

you can use this to make deep water aswell, look map01 on the mega wad
Alien Vendetta

its usefull, works even for the buggy doom95 engine

Not exactly; slime trails are a specific and unwanted type of flat bleeding caused by imprecision in a map's nodes. While there are some cases where intentional full-sector flat bleeding can be used for effects, slime trails they are not, and even more importantly they aren't related to vanilla deep water: those would be invisible, self-referencing sectors. :)

02-16-10 08:05 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

D_GARG
Forum Regular

Posts: 739
Registered: 12-09

esselfortium said:

Not exactly; slime trails are a specific and unwanted type of flat bleeding caused by imprecision in a map's nodes. While there are some cases where intentional full-sector flat bleeding can be used for effects, slime trails they are not, and even more importantly they aren't related to vanilla deep water: those would be invisible, self-referencing sectors. :)

ok, but look the wad then u know what i mean :)

02-16-10 08:34 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

NaturalTvventy
Member

Posts: 518
Registered: 06-09

So now that we've clearly defined smile trails, any idea on how to fix the problem?

02-17-10 01:12 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Gez
Why don't I have a custom title by now?!

Posts: 6457
Registered: 07-07

Shift your vertices around until the problem disappears.

02-17-10 01:24 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

StoneFrog
Member

Posts: 276
Registered: 06-08

We can't really point them out for you, you're going to have to just tear through your map trying to fix the individual trails.

You say that you switched from DETH to Doom Builder 2 - I myself have only ever mapped using DB(2) but this may have messed up the map. Not the actual WAD, but both editors probably have very different ways of reading the map formats and processing linedefs differently.

Not all slime trails are caused by NodeBuilder errors, they could simply be from missing upper/lower textures or something similar. I'd suggest running an Analysis (look for the checkmark icon) on your map in Doom Builder, seeing if you've any double-sided linedefs that are only assigned to one sector, missing textures, all sorts of screwy things like that.

I'm not sure just how complex your map's geometry is, but if possible, could you just upload a quick screenshot of the map's geometry from Doom Builder?

02-17-10 01:27 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

esselfortium
Cumulonimbus Antagonistic Posting

Posts: 5152
Registered: 01-02

StoneFrog said:
You say that you switched from DETH to Doom Builder 2 - I myself have only ever mapped using DB(2) but this may have messed up the map. Not the actual WAD, but both editors probably have very different ways of reading the map formats and processing linedefs differently.

Er...no, unless something is severely broken with a map editor, it should be loadable in any other editor just like it can be loaded in any version of Doom.

02-17-10 01:30 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

StoneFrog
Member

Posts: 276
Registered: 06-08

Oh? Just guessing, then - I'm specifically referring to line/sidedef flags, was thinking maybe something would only register or be interpreted in a different way by one of the two editors. Guess not.

02-17-10 01:32 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

NaturalTvventy
Member

Posts: 518
Registered: 06-09

here's some pics of the geometry.

http://i613.photobucket.com/albums/...limetrails2.jpg

http://i613.photobucket.com/albums/...slimetrails.jpg

lots of diagonal lines.

and one of many examples of the slime trails...

http://i613.photobucket.com/albums/...3slimetrail.png

grrr annoying. From what I'm getting it sounds like there's no good solution but moving verticies, but i worry that this will be an endless slimetrail hunt as more pop up to replace the old. and I'm left wondering why they all popped up all of a sudden in places that never had them before. it's not like they've been around from the get-go, most of 'em are in areas that i made a while back and had been fine til I made my editor switch.

missing textures cause slime trails? i have a million missing textures, some for various effects and some just in areas the player will never see.

02-17-10 02:36 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

esselfortium
Cumulonimbus Antagonistic Posting

Posts: 5152
Registered: 01-02

NaturalTvventy said:
missing textures cause slime trails? i have a million missing textures, some for various effects and some just in areas the player will never see.

Not exactly, no. Not what you're getting, and they wouldn't be called slime trails. What you have is just, unfortunately, from node-format imprecision due to all the odd angles and off-grid stuff (well, not *due to*, but it makes it far more likely), and jiggling vertices around is pretty much all that can be done. :(

02-17-10 03:04 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

NaturalTvventy
Member

Posts: 518
Registered: 06-09

So I've been trying to come up with a reason why the slime trails are new with my switch to DB2. I have a theory. when I was using DETH i didn't build the nodes externally, instead I just tested the map using ZDOOM and let ZDOOM do whatever it does to build nodes when it sees it's loading a level that needs the nodes built. Graf up there said something about ZDBSP's suppressed nodes which don't produce slime trails. Is this what ZDOOM does when it builds the nodes while loading a WAD?

I'm thinking that when I switched to DB2 I started building the nodes in DB2 before running ZDOOM, using ZDBSP but perhaps not compressing nodes. I'm still testing the map in ZDOOM, but I'm wondering if ZDOOM is now recognizing that the nodes are pre-built and thus not doing what it used to do, and in the end running a version of the map that has all the slime trails.

It's what I've come up with. Bummer that they are there, I always thought that good node builders remove slime trails.

NT

02-17-10 04:10 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 6962
Registered: 01-03

NaturalTvventy said:
Graf up there said something about ZDBSP's suppressed nodes which don't produce slime trails. Is this what ZDOOM does when it builds the nodes while loading a WAD?

It's 'compressed' nodes and yes, if ZDoom internally builds nodes it preserves the vertex coordinate precision. And your screenshots show a kind of level geometry that may be prone to slime trails

It's what I've come up with. Bummer that they are there, I always thought that good node builders remove slime trails.

NT

In a way they do. They try to avoid diagonal splits as much as possible because these contribute the majority of slime trails. But in the end it's a task that's not really doable automatically. If a node builder had to discard every split that could produce slime trails it wouldn't be able to build nodes at all.

It's really too bad that there's no commonly supported node format that fixes these problems.

Compressed nodes are only supported by ZDoom (and I really don't understand the reluctance of other programmers to support this format) and the only alternative - GL nodes - are also only supported by a limited number of ports. And it's not possible to combine both in the same map.

02-17-10 07:16 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

andrewj
Senior Member

Posts: 1344
Registered: 04-02

Graf Zahl said:
Compressed nodes are only supported by ZDoom (and I really don't understand the reluctance of other programmers to support this format)

Probably because they've never heard of it, or consider it such a low priority that it never gets done. The requirement to uncompress them is also a barrier to adoption.

And it's not possible to combine both in the same map.

I don't see any reason why "Z Nodes" and GL Nodes cannot both be used on the same map.

02-17-10 07:57 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

DaniJ
Senior Member

Posts: 1691
Registered: 08-03

Graf Zahl said:

Compressed nodes are only supported by ZDoom (and I really don't understand the reluctance of other programmers to support this format) and the only alternative - GL nodes - are also only supported by a limited number of ports. And it's not possible to combine both in the same map.

Newer releases of Doomsday ignore all prebuilt nodes regardless of format, instead, opting to build its own during the conversion of maps into it's native representation.

02-17-10 10:07 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 6962
Registered: 01-03

Well, that may be good for your renderer but it will most definitely cause some problems. There's maps out there that won't be rebuilt properly.

I have never managed to get any node builder to build fully working nodes for P:AR E1M3, for example. This map contains some bad overlapping sectors so that most node builders create some holes.

For that reason I always load the prebuilt nodes in GZDoom but if they aren't GL nodes I only use them for in game sector lookup. So there can be 2 sets of node being in use at the same time.

02-17-10 10:38 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Gez
Why don't I have a custom title by now?!

Posts: 6457
Registered: 07-07

Graf Zahl said:
Compressed nodes are only supported by ZDoom (and I really don't understand the reluctance of other programmers to support this format)

Quasar was considering it, with Mordeth egging him on.

02-17-10 11:24 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

DaniJ
Senior Member

Posts: 1691
Registered: 08-03

Graf Zahl said:
Well, that may be good for your renderer but it will most definitely cause some problems. There's maps out there that won't be rebuilt properly.

That doesn't really compute for me. What you are inferring is that there are maps which rely on an improperly formed node structure. What they are actually dependant on is DOOM's interpretation of the nodes (P:AR E1M3 being a case in point).

The reason we ignore the prebuilt nodes is precisely because it allows us to tailor construction to suit Doomsday's requirements and thus avoid the inherent problems with trying to interpret the output from a dozen different nodebuilders.

02-17-10 12:02 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 6962
Registered: 01-03

DaniJ said:

That doesn't really compute for me. What you are inferring is that there are maps which rely on an improperly formed node structure. What they are actually dependant on is DOOM's interpretation of the nodes (P:AR E1M3 being a case in point).

With overlapping sectors it depends on the actual node output which sector gets assigned to a specific subsector in case it is formed by linedefs belonging to different sectors.

In this case there were self-referencing sectors overlapping with other linedefs but it was done in a way that there were rather large chunks which couldn't get an unambiguous sector assignment. My suspicion is that the nodes being built for this map were tweaked by command line options until it worked. Not the best method if you ask me...

02-17-10 13:24 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

DaniJ
Senior Member

Posts: 1691
Registered: 08-03

I see. That explains why the problems disappear if you don't produce segs along "self-referencing" linedefs (where did that name come from in the first place? Its not nearly an accurate description).

02-17-10 17:02 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 4484
Registered: 08-00

ZDoom nodes probably would have been much more widely adapted if they were:

not redundantly compressed
more thoroughly set apart from standard level data

At least I know those are the two things that bug me about them personally.

If you're not sure what I mean by point 2, it's the fact that ZDoom nodes go inside some of the standard lumps, and only use a single word of header magic to identify themselves, which simultaneously confuses ports that don't know about them and runs the risk of accidental aliasing of ordinary data. An additional checksum and guard words would make such aliasing exponentially more improbable.

02-17-10 17:56 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 6962
Registered: 01-03

I have to agree but this was done long before my involvement in ZDoom.
On the other hand, what would have been better? GL nodes still suffer from bad tool support. Far too many things out there strip them out because they have no clue what they are.

The compression, however, ultimately was a stupid idea. Back in the day there was no Zip support as WAD replacement so it may have had some use but now it's more or less useless. On the other hand, for any source port that uses zlib elsewhere this shouldn't be a problem.

02-17-10 18:08 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 6962
Registered: 01-03

DaniJ said:
I see. That explains why the problems disappear if you don't produce segs along "self-referencing" linedefs (where did that name come from in the first place? Its not nearly an accurate description).

And how do you determine the proper sector the player is in in case some sector hacks are involved? If you do not produce segs for such linedefs it should work even less if you use the same data for in game sector lookup.

02-17-10 18:10 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

DaniJ
Senior Member

Posts: 1691
Registered: 08-03

You don't need to. Self-referencing linedefs are never involved in collision detection. We don't use linedefs for sector look up.

02-17-10 18:28 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

esselfortium
Cumulonimbus Antagonistic Posting

Posts: 5152
Registered: 01-02

Err...how do you support vanilla 3D bridges, then?

02-17-10 18:34 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

DaniJ
Senior Member

Posts: 1691
Registered: 08-03

First I must declare that none of this is in a current release build.

Segs for self-referencing linedefs are generated as a secondary stage which occurs after the nodes have been built. These segs are then inserted into the BSP, splitting as necessary where any intersections occur with the normal segs (and each other), linking them as an additional list of segs per subsector. They are then drawn along with regular walls (possibly occluding), sorted in with sprites.

Naturally there is additional overhead for sprite sorting with such a scheme, hence I've been working on a method to have them pre-sorted once by subsector during map load.

02-17-10 18:49 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 4484
Registered: 08-00

DaniJ said:
Segs for self-referencing linedefs are generated as a secondary stage which occurs after the nodes have been built. These segs are then inserted into the BSP, splitting as necessary where any intersections occur with the normal segs (and each other), linking them as an additional list of segs per subsector. They are then drawn along with regular walls (possibly occluding), sorted in with sprites.

That is very similar to the principle on which Eternity's dynasegs function :)

02-17-10 19:47 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

All times are GMT. The time now is 12:38.

Pages (2): [1] 2 »

Doomworld Forums > Classic Doom > Doom Editing > Slime trails

Show Printable Version |

Email this Page |

Subscribe to this Thread

Forum Rules:

You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON

< Contact Us - Doomworld >