Derspegn on 12/9/2015 at 01:50
I am framing a question based on the following link and photos at the end of this post: (
http://ttlg.com/forums/showthread.php?t=141443)
A house in my mission has a pyramid-shaped roof with a square base. Initially I was using grid size 14, but had to leave the roof slightly above the square brushes. If I tried lowering the grid size to bring the roof closer and portalized, I would get the "draw surface: too many vertices" error. When I moved all of the house slightly lower than the bottom face of the surrounding environmental air brush, the error disappeared after portalizing. But the error returned when I added extra shapes, and I want to move the house to its original place if possible. I have a number of buildings on the grid, and this is the only one that I've had this problem with, even when using grid size 9.
Today I found the thread that deals with the problem, and in it Yandros suggested keeping the grid size at 13 or above, snap to grid, and optimize instead of portalize. However, when I have snapped to grid on size 13 or 14 and simply portalized, it dislocates things like doors, and I have had to readjust everything. In another case it enlarged some balustrade cubes that I made on another brush. Plus the lower grid size enables me to zoom in and get the brushes snug right where I need them.
So my question is: Will optimizing after snapping to grid take care of the dislocation and shape changes, or will I still need to readjust everything? Excuse my lack of familiarity, as I haven't used Dromed like some of y'all have.
Inline Image:
http://i.imgur.com/D0UHU2N.png?1Inline Image:
http://i.imgur.com/lvSws6u.png?1LarryG on 12/9/2015 at 15:18
I suggest that you read OPTIMIZE.DOC. It is included with your CD. I would further suggest that you try changing the slope of the roof such that the pyramid bottom lines up nicely with your house walls / soffit. Also, there is nothing sacred about grid size 14 or 13. Those are good values to use when roughing in your large pieces of geometry, but there is nothing wrong with getting down to grid size 11 when adding in fine details later on.
[ATTACH=CONFIG]2183[/ATTACH]
qolelis on 12/9/2015 at 16:42
Quote Posted by Middoth
A house in my mission has a pyramid-shaped roof with a square base. Initially I was using grid size 14, but had to leave the roof slightly above the square brushes
The thing I usually did in this situation was to use the command
set_grid, which makes all vertices of the currently selected brush snap to grid, which makes it possible to align most non-cube brushes to cube brushes. Be careful with that command, though: it is a powerful tool, but also has the potential to distort brushes in illegal ways if you are not careful.
R Soul on 12/9/2015 at 20:07
set_grid is not a wise thing to suggest to someone who's new to Dromed. Or to someone who's been using Dromed for years. :joke:
Middoth, just for info, all the grid does is round off brush coordinates and dimensions. Coordinates can always be twice as precise than dimensions.
11: Coords multiples of .125, dims multiples of .25
12: Coords multiples of .25, dims multiples of .5
13: Coords multiples of .5, dims multiples of 1
14: Coords multiples of 1, dims multiples of 2
15: Coords multiples of 2, dims multiples of 4
16: Coords multiples of 4, dims multiples of 8
If a brush for a doorway won't line up with the door object at grid size 13, check the object's coordinates. Most doors have a height and width of a whole number, but you need to make sure the coordinates are rounded off.
qolelis on 12/9/2015 at 21:08
Quote Posted by R Soul
set_grid is not a wise thing to suggest to someone who's new to Dromed. Or to someone who's been using Dromed for years. :joke:
Well, to be honest, DromEd is not a wise thing to suggest to someone who is new to DromEd - or even to someone who has been using DromEd for years. :joke: That shouldn't stop anyone from using it, though; the more you know etc...
Anyway, set_grid is sometimes the only* way to do things, and it can even also save cells (which has saved me a few times in the past), so the sooner one knows about it, the better, I'd say.
-----
* Usual disclaimers apply...
Xorak on 13/9/2015 at 07:52
Quote Posted by Middoth
Today I found the thread that deals with the problem, and in it Yandros suggested keeping the grid size at 13 or above, snap to grid, and optimize instead of portalize.
If you snap to grid in the above sequence, make sure your grid is set to the lowest grid number you have used, otherwise it will realign everything to grid 13 (in this case). And if that pyramid is not working for you, try and build the shape with two wedges instead, they might also line up nicer as well if you're having a problem there.
Derspegn on 14/9/2015 at 00:50
Quote Posted by R Soul
Most doors have a height and width of a whole number, but you need to make sure the coordinates are rounded off.
When I have rounded coordinates off, they have reverted by themselves to numbers with decimals above zero. Is this due to the grid size?
john9818a on 15/9/2015 at 11:44
Another approach that uses a few more brushes is to put a solid brush where tje roof should be and use four inverted wedges to cut away the solid ti form sloped roof on four sides. A lot of times pyramids give portalization problems.
Derspegn on 15/9/2015 at 21:47
I will be looking at modifying the pyramid, but I discovered what was causing the problem:
On a separate building, I have an open porch stage fronted by a wooden railing. I saw Von Eins' railing in an FM, but wanted to make my own to save on polys. Now here's where that error message comes in: first the rail posts were 6-sided cylinders, and I was receiving the same error (I forgot about this later when moving the pyramid roof on the other brush). So, I transformed them into rectangle cubes. If I got the error, I put it on the back burner and moved on. When I moved the pyramid roof and portalized, not only would I get the error in Mono, but also in Game Mode. At the time I didn't know how to locate number the brush the warning message was identifying as having too many polys. But it was the face of one of these cube rails that apparently was conflicting with the movement of the other brush.
I have deleted my own railings and replaced them with Von Eins'. The replacements are single objects, each containing three rails. Now the error has disappeared.
john9818a on 16/9/2015 at 03:59
Actually using brushes instead of objects will increase polys especially with repetitive detailed work, but I'm glad you got it solved. :thumb:
