[NEED HELP] Micro-seams in Compiled Map

I have a double helix staircase and obviously everything isn't going to align perfectly with the grid. When it's compiled thankfully every brush remains as is, but if you look hard enough there's some micro-seams along the curve. 
I figure if I exported the brush to .obj and put in that .obj as a model it'd get rid of that seam issue (since the edges touch in-editor), but everytime I do that I just get a small cube with a no shader texture on it.

What do I do to get rid of these micro-seams?

I tried to follow along with this.
https://www.katsbits.com/tutorials/idtec...vanced.php

The mesh is full of gaps/holes:



It is better if every vertice of a brush meets a vertice of neighbour brush.

.

   


   


Example map and model


It is an example of how to build some geometry with "modular" models made from brush work.


.

I keep getting 

Code:

Model load failed: "/home/user/.xonotic/data/infinity-improv4.pk3dir/models/stairs_test.obj"

entityCreate -class misc_model 

   

It seems a problem in your end.

But it is only a test  trying to show you that you can create your stairs with a bunch of brushes with no gaps between them.

Can you open the stairs_test.map to see how I have built the small piece of circular staircase?

,

Model load failed: "/home/user/.xonotic/data/infinity-improv4.pk3dir/models/stairs_test.obj"

apparently 'make path relative' doesn't work for this
is it the path, radiant sees?
i suggest to enable logging and to post full log

I just extended my mapping scripts and also added an example on how to generate spiral stairs with it:
https://github.com/DefaultUser/AssetGene..._stairs.py
At some point I will create easy to use asset generator classes and maybe even a GUI.

I think those seams exist because the inner and outer ramp segments can not be created by one brush each. You can see in my script that I split those into two brushes.

micro-seams

outer ones are just caulk, lol; +vertices may be coincident there
cracks between steps is known issue; q3map2 does too nasty snapping or something, code logic probably expects integers; requires investigation
snapping to grid fixes these ones for me (snapping breaks some parts tho, since vertices do not meet each other here and there)

It seems a problem in your end.

But it is only a test  trying to show you that you can create your stairs with a bunch of brushes with no gaps between them.

Can you open the stairs_test.map to see how I have built the small piece of circular staircase?

,

Yeah I saw.

I just extended my mapping scripts and also added an example on how to generate spiral stairs with it:
https://github.com/DefaultUser/AssetGene..._stairs.py
At some point I will create easy to use asset generator classes and maybe even a GUI.

I think those seams exist because the inner and outer ramp segments can not be created by one brush each. You can see in my script that I split those into two brushes.

micro-seams

outer ones are just caulk, lol; +vertices may be coincident there
cracks between steps is known issue; q3map2 does too nasty snapping or something, code logic probably expects integers; requires investigation
snapping to grid fixes these ones for me (snapping breaks some parts tho, since vertices do not meet each other here and there)

I went and snapped my stairs and the walls to the 1 grid, a column of vertices at a time and got it to fully close.

Do not use quadratic brushes to build your staircase or you will have gaps.


It is better to use triangular brushes (probably the only way) :

   


.

I have the same problem on my kolossus map. I even redid the part where it occured without success. I believe it's where the q2 engine hits the precision limit of the floats. But on the other hand it puts 2 points close together which should be on one point anyways... Maybe sin() is not precise enough?

Like you did here @30sec:
https://www.youtube.com/watch?v=qA9eNOkD1iY
I did that a bit bigger and with 36 sides.

Also messed up some parts where I copied brushed I rotated. (Converted it to a model in radiant, and imported it that way so the radiant wont mess up the vertices...).

@_para can you provide reproducible examples of bugs you'v got?
I'v got grip with this problem; not quite sure what to do with it and if to do at all -)
basically q3map2 does snap brush drawsurfs vertices to 0.125 grid
obvious reason to do so is to prevent a lot of fairly tiny cracks
idk if there are more reasons, also other parts of code might rely on this in theory, so change may be risky, up to crash with specific circumstances
...so if you have your brushes not super accurate, some of meant to be equal vertices snap to different points
snapping brushes in editor helps for sure + is actually snapping vertices in recent version; so only not applicable case is T-junction
i found q3map2 fork, which does slower and theoretically more qualitative weld pass instead of this snapping
also lowering snapping grid by factor of 4 helps with offgrid brushes on the very edge of world
offgrid stairs from my video actually work well with any option (.125, .125/4, weld), except one crack after weld
model-doublehelixstairs.map is initially inaccurate; you can see cracks at inner spiral in editor even, and i'v got no options helping with this; weld is using 0.1 epsilon, perhaps more would solve this, but break possibility of tiny geometry; as for cracks between steps, weld or lower epsilon solve them

I tried following along with this and I had trouble understanding what you are doing. If you wrote out steps of what you're doing as opposed to making a video, that'd help more.

There is new `repeat transform` command from wip version used; might be replaced by doing rotation and move for every copied bit.
The rest might be read from key/mouse log from video.
Writting out every keypress would be overkill; which steps aren't clear for you?
Funny tho, usually people vote for video and not the text

There is new `repeat transform` command from wip version used; might be replaced by doing rotation and move for every copied bit.
The rest might be read from key/mouse log from video.
Writting out every keypress would be overkill; which steps aren't clear for you?
Funny tho, usually people vote for video and not the text

I learned using NetRadiant from:

http://de.ws.q3df.org/level_design/radiant_tutorials/

If you want my rationale of text over video, the majority of video tutorials come with narration and come with explanation of what's being done, not simply a video of something being done with background music. There's also a lot of ways to do narration wrong and end up getting across the same information extremely inefficiently i.e reading through that tutorial will get someone done on their first room sooner than watching a video.

If you're going to have the viewer read console output, seek back and forth, to figure out what you're doing, it defeats the purpose of a video format. Also it doesn't make much sense to make a tutorial making use of a function that doesn't exist in a release build.

I consider text tutorials way more efficient over video ones, even if latter have narrations.
This video is more like a game demo, which is fun to record and watch, and which still may be used as a guide by reading keypresses at low speed, if you are not familiar with the game enough.