who says we can't make trees?

[whirlingdervish]

[glow=green,2,300] The Tree Discussion/Argument [/glow]

So far I'm convinced that it can be done...
prefab trees might help a little..

the only downsides being the extremely high detail
and the need to transform them all a bit so they don't look identical...

Anyone have any viable ideas? trees, bushes, vegetation related comments in general?
(other than "It can't be done!")

[grieve[Q2C]]

it's a pity I've lost ricebug's tutorials. and they don't seem to be online anymore. in one of them he covered this subject too.

he used trees in one of his Doom conversions. the 3rd episode. E3M6, MT. EREBUS.



generally there is no problem. it is just that vis will have to calculate a VERY long time when you forget setting the trees as details.

[whirlingdervish]

is there any change in the gameplay if you set them as details?
can you walk on them, jump off them?

i was also thinkin about how to do other types of veggies and I did manage to make
a reasonably decent looking clump of grass.. not suitable for doing a grass-covered hill though.. it would take a whole lotta pollies... but its a nice garnish to put next to a rock or a wall or something..

[grieve[Q2C]]

for gameplay it's irrelevant. the engine only cares about the number of polys it has to render. in an open area everything is visible anyway, the bsp tree (sic) has no noticeable effect for the ... ummm ... other trees, but it takes a VERY long time to be calculated.

and you could use a texture for the rocks which suggests that they are overgrown with moss.

[grieve[Q2C]]

fool the compiler ? why ?
no, setting brushes as detail is completely legitimate.

a map is playable after the bsp is built, without vis-ing and light-ing it. the bsp tree which is calculated by qbsp is not essential for the engine to render the map. it only helps to render the map faster.

it helps the engine to decide which parts of the map are visible from which other parts, so it does not need to draw the whole map all the time with the inclusion of the actually invisible parts.


this is especially effective in buildings and other places which consist of different visibility areas. wherever you stand and look, the engine has a hint what is visible from the point where you stand and can skip the rest.

in space maps and open places - or landscapes - the whole scenery is visible anyway, if there is nothing around to block visibility.
setting an object as detail only tells the vis compiler that this object need not be taken into consideration when the bsp tree is calculated.

for trees, it would not have a noticeable effect and would not justify the escalation of the vis time from 5 minutes to 5 days.

;D

[whirlingdervish]

ok, so you set the tree as a detail and it doesn't bother to render it from every angle on the map that it is visible from?
so the amount of time it takes to render the map is cut down because it doesn't have 1000 extra polygons per tree to render from every location...

so this would work to speed up the rendering time for most highly detailed groups of brushes
that are visible from various angles in the map...

can you still see them from the same distance away, and all the same angles, as if you rendered them fully?

[3fing3redfi3nd]

Where can I find a copy of that Doom conversion?

[grieve[Q2C]]

terminology is getting unclear here. if detail brushes belong to a certain vis area, are they visible from other vis areas anyway, even if the whole area they belong to is invisible from there ?

for func_walls this seems to apply. when I get the "sky bug" and look through sky brushes, getting a ghost view of hidden areas of the map, func_walls are visible in areas which are otherwise completely invisible.

is the same true for detail brushes ? I doubt it anyway, but I'm not sure.

maybe this tutorial can help us to clear this up.

www.gamedesign.net/node/266

[whirlingdervish]

wow that was very informative. I completly understand what you were getting at now.
They lose precedence with the vis compiler so it doesn't split a bunch of nodes around each of the many polys per tree.
thx dude.

[grieve[Q2C]]

[grieve[Q2C]]

3fing3redfi3nd said:

Where can I find a copy of that Doom conversion?

fortunately someone uploaded it to this server:

[ftp]ftp://65.25.162.32/quake2/scrapple/Levels/Doom/[/ftp]

if it is temporarily unavailable, try a later.

if you are also looking for the third part of Doom 2 (d2_part3.zip), I could provide this one. But it would be slow to download.

[3fing3redfi3nd]

Which file am I going after here? Seem to be a bunch on that link.

[grieve[Q2C]]

kneedeep.zip - Doom1 Episode1
shores_of_hell.zip - Doom1 Episode2
inferno.zip - Doom1 Episode3
tfc.zip - Doom1 Episode4 (Ultimate Doom)

Doom 2 : d2_part1.zip
d2_part2.zip
d2_part3.zip


kneedeep is still a bit clumsy in some places, from there it got better very fast. I'd recommend getting all this stuff.

[whirlingdervish]

these are cool. thx bro!

[strider]

(by Knightmare)


www.markshan.com/knightmare/pics/pax3_3.jpg
www.markshan.com/knightmare/pics/pax3_4.jpg