Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
NaturalTvventy

Slime trails

Recommended Posts

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.

Share this post


Link to post

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.

Share this post


Link to post
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. :)

Share this post


Link to post
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 :)

Share this post


Link to post

Shift your vertices around until the problem disappears.

Share this post


Link to post

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?

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post

here's some pics of the geometry.

http://i613.photobucket.com/albums/tt214/emilharold/slimetrails2.jpg

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

lots of diagonal lines.

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

http://i613.photobucket.com/albums/tt214/emilharold/end3slimetrail.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.

Share this post


Link to post
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. :(

Share this post


Link to post

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

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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...

Share this post


Link to post

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).

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post
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 :)

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×