Page 1 of 2 1 2 LastLast
Results 1 to 20 of 24

Thread: T-junction vertexes (was Q3Map2.5.4 draws to many vertices)

  1. #1
    Fiesling
    Guest

    T-junction vertexes (was Q3Map2.5.4 draws to many vertices)

    The r_speeds of my maps rose up around 5k in open terrain. So
    I floated around with tris on and saw this:



    But in my editor this brush is just a normal 6 sided structural brush.



    It looks like itersections to me, but there can't be intersections. I took a look at the skybox brushes and saw the same phenomenon.

    I compiled with this options:

    -meta -patchmeta
    -vis
    -light


    What is -merge for?? Everytime i use it the q3map2.5.4 crashes.

  2. #2
    when you compile your map q3map2 calculates the map only in polys which are 3 sided, so a square brush at least has to become 2 verts, a 6 sided, maby clipped or deformed brush will need a lot more so what you see is absolutely normal and should be like that, sides that are caulked are not calculated at all so try to caulk wherever possible

    oh - just saw that it's you fiesling, guess you knew that already heh? so just ignore me
    Never argue with an idiot, he'll lower you to his level and then beat you with experience!

    http://www.wolfproject.net
    http://www.kingludwigsarmy.de

  3. #3
    It was always my understanding that a brush like the one in your example is split into that many polygons to prevent t-junctions from occuring. The compiler has to create a vertex on the outside edge of the floor brush at every point where a wall brush vertex lies.

  4. #4
    Fiesling
    Guest
    so a square brush at least has to become 2 verts
    Yes i know that, but like in the ingame shot there should be only one line from one side to the opposite one. but not this structure.
    like i said this brush is only 6-sided with no intersections or deformations.
    the bottom is caulked.

  5. #5
    Since it appears you have ignored my previous post, I will try once more with a more visual representation.

    there should be only one line from one side to the opposite one.
    This method would produce sparklies all along the light blue lines. Thankfully, q3map2 doesn't do this.


    This method is as I described previously, where the floor brush is subdivided so that its verts line up with adjacent verts. This prevents sparklies.

  6. #6
    Bravo, chavo.

    Quick, someone archive this thread!

    Oh wait...


  7. #7
    Fiesling
    Guest
    Now i understand. :banana:
    Then i have to change my mapping-technics a little bit. Old Q3map1 didn't do that and i never got sparklies before.

    Thanks. :drink:

  8. #8
    as i understand it this could be also prevented by having q3map_notjunc on the floor shader. but with possibility of having sparklies then. right ydnar?

    i had the same effect like fiesling on a water shader without deformVertexes and q3map_notjunc did help there

  9. #9
    Fiesling
    Guest
    I recompiled my map with -notjunc and all went fine. Better r_speeds and no sparklies.

  10. #10
    I was under the impression that Charvo's example above would work with -notjunc since the walls and floor meet at right angles and the brushes involved haven't been rotated - so it all fits together nice and snug along the join - err that's my non-technical wording!

  11. #11
    Unless you're completely fastidious about sealing areas and jointing brushes, -notjunc is not really a good solution.

  12. #12
    I understand the principle, but I don't understand how we can prevent it from happening to create less tris.
    Project Lead / Design / Level Design
    Dark Horizons
    http://www.planetunreal.com/darkhorizons

  13. #13
    Junior Member
    Join Date
    Jun 2003
    Location
    Baal, Belgium
    Posts
    1
    Most Recent Awards:

    Yeah how about a solution to prevent this from happening for the not so experienced readers (like me) since notjunc isn't a good method. My R_speeds went beserk when compiling with 2.5.4.

    Oh and Hi all since this is my first post :drink:

    UPDATE: Just tried recompiling it with 2.5.5 test3 and all seems in order again
    Current Project: ut_triggerhappy

  14. #14
    Quote Originally Posted by ydnar
    Unless you're completely fastidious about sealing areas and jointing brushes, -notjunc is not really a good solution.
    Besides the sparkles are there any other problems with using notjunc. I have some massive splits in certain places that aren't frequently visited and I don't care about sparkles there so I need an option like this. If the only bad side effect of -notjunc are the sparkles then fine, if it causes bugs then tell me.

  15. #15
    i use -notjunc for quick test compiles where i only want to check geometry or entities. difference in compile time is really stunning: 30 sec. for bsp instead of 7 minutes
    http://www.pazurmapping.com - Maps, Shaders, Tutorials and more...

  16. #16
    i think I'm not understanding this right.
    Can notjunc be used in a shader to eliminate the excess splits just for that texture, or is it a compiler argument that applies to the whole map?

    I want something that i can apply to specific surfaces in my map to override the default triangle splits.

  17. #17
    They aren't "default triangle splits." They are additional vertices to fix a T-junction of an edge meeting a vertex which would cause a crack (sparklie) due to the hardware FP imprecision.

    The only way to avoid them is to become aware of what causes them and map to avoid them, usually by not putting lots of brush corners adjacent to longer brush edges.

    y

  18. #18
    some things are easier to avoid than others.

    So far neither of my questions have been answered. One being if notjunc cause any bugs (is it a fully supported feature). And the other if notjunc can be aplied as a shader parameter that will work on one surface only and not a compiler directive that applies to the whole map. I did try applying it to the whole map and it works somewhat well. I say somewhat because it didn't do everything. Some faces it seemed to have ignored.

    Anyway sorry for being rude, but sometimes when you ask a question you expect sort of a direct answer instead of the usual design your map better.

  19. #19
    Quote Originally Posted by Machine for to kill
    Can notjunc be used in a shader to eliminate the excess splits just for that texture
    First of all, they are not excess splits. They are splits that are only made if your brush construction requires them in the prevention of sparklies. Everyone thinks q3map2 is doing a bad thing here, but it's not.

    As for the shader directive you are looking for, it's called "q3map_notjunc".

    Quote Originally Posted by q3map2 handbook
    q3map_notjunc
    With this option, surfaces modified by a shader are not used for t-junction fixing. q3map_noclip and q3map_notjunc, used in combination, will preserve mesh geometry exactly as you make it.
    As for your question on bugs, yes, I consider sparklies to be bugs.

  20. #20
    thank you chavo

    How's venice doing?

Bookmarks

Posting Permissions

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