Mars.exe - как??? (2 стр)

How to draw each frame
----------------------

First, draw the sky, and blank off about 50 or so scan lines below the
horizon since the routine may not write to all of them (eg. if you are on top
of a high mountain looking onto a flat plane, the plane will not go to the
horizon).
Now, down to business. The screen is as follows:

    ---------------------------
    |                        |
    |                        |
    |          Sky          |
    |                        |
    |                        |
    |a------------------------| Horizon
    |                        |
    |                        |    Point (a)=screen co-ords (0,0)
    |          Ground        |    x increases horizontally
    |                        |    y increases downwards
    |                        |
    ---------------------------

Imagine the viewpoint is at a position (p,q,r) where (p,q) are the (u,v)
map co-ordinates and r is the altitude. Now, for each horizontal (constant v)
line of map from v=r+100 (say) down to v=r, do this:

  1. Calculate the y co-ordinate of map co-ord (p,v,0) (perspective transform)

  2. Calculate scale factor f which is how many screen pixels high a mountain
of constant height would be if at distance v from q. Therefore, f is small
for map co-ords far away (v>>r) and gets bigger as v comes down towards r.

  3. Work out the map u co-ord corresponding to (0,y). v is constant along
each line.

  4. Starting at the calculated (u,v), traverse the screen, incrementing the
x co-ordinate and adding on a constant, c, to u such that (u+c,v) are the map
co-ords corresponding to the screen co-ords (1,y). You then have 256 map
co-ords along a line of constant v. Get the height, w, at each map co-ord and
draw a spot at (x,y-w*f) for all x.

Sorry, but that probably doesn't make much sense. Here's an example:
Imagine sometime in the middle of drawing the frame, everything behind a
point (say v=q+50) will have been drawn:

    ---------------------------
    |                        |
    |                        |
    |                        |
    |          ****          |
    |        *********        | <- A mountain half-drawn.
    |-----**************------|
    |*************************|
    |*********      *********|
    |******            ******|
    |.........................| <- The row of dots is at screen co-ord y
    |                        |  corresponding to an altitude of 0 for that
    ---------------------------  particular distance v.

Now the screen-scanning routine will get called for v=q+50. It draws in a
point for every x corresponding to heights at map positions (u,v) where u
goes from p-something to p+something, v constant. The routine would put points
at these positions: (ignoring what was there before)

    ---------------------------
    |                        |
    |                        |
    |                        |
    |                        |
    |                        |
    |-------------------------|
    |          *****          |
    |      ***    ***      |
    |*******          *******|
    |.........................|
    |                        |
    ---------------------------

So, you can see that the screen gets drawn from the back, one vertical
section after another. In fact, there's more to it than drawing one pixel
at every x during the scan - you need to draw a vertical line between
(x,y old) to (x,y new), so you have to have a buffer containing the y values
for every x that were calculated in the previous pass. You interpolate
along this line (Gouraud style) from the old colour to the new colour also,
so you have to keep a buffer of the colours done in the last pass.
Only draw the vertical lines if they are visible (ie. going down,
y new>y old). The screen is drawn from the back so that objects can be drawn
inbetween drawing each vertical section at the appropriate time.

If you need further information or details, mail me or post here... Posting
will allow others to benefit from your points and my replies, though.

Thank you for the response I have received since uploading this program.

Tim Clarke,

Источник что называется:
From rc1.vub.ac.be!ub4b!EU.net!sunic!news.funet.fi!network.cc.jyu.fi!network.cc.jyu.fi!not-for-mail Thu Mar 10 10:07:29 1994
Path: rc1.vub.ac.be!ub4b!EU.net!sunic!news.funet.fi!network.cc.jyu.fi!network.cc.jyu.fi!not-for-mail
From: (Patrick Aalto)
Newsgroups: comp.sys.ibm.pc.demos
Subject: Re: How in the world did they do MARS.EXE?
Date: 1 Mar 1994 14:28:59 +0200
Organization: University of Jyvaskyla, Finland
Lines: 171
Message-ID: <2kvceb$>
References: <2ku50l$>
NNTP-Posting-Host: tukki.cc.jyu.fi

In article <2ku50l$> (Kevin McCormick) writes:
>Now I've pondered quite a bit how it's done.

Why bother pondering, since the person who created the demo was
kind enough to post a description of the mothod, too. He did
this at least in the 'rec.games.programming' and 'comp.graphics.
algorithms' newsgroups. I think it might be a good idea for all
the readers of this conference to visit those two, too (at least
I do that).

In any case, here's the description. I hope Tim Clarke don't mind...

Patrick Aalto

Demiurg-HG
Что такое 4-dof?
4 степени свободы (degrees of freedom). Это перемещения по 3-м осям
и поворот вокруг горизонтальной оси. Современные движки все 6-dof, т.е.
позволяются крутиться и перемещаться как угодно и куда угодно. Поэтому
4-dof ограничение довольно существенно, в частности неудастся создать
авиасимулятор, зато авто- пожалуйста.

azazello
воксели имеют одну прелесть - они аппартно не ускоряются на данном
этапе развития (и я не слышал, чтобы в обозримом будущем ситуация изменилась).
А так - интересная технология.
Не будь так категоричен. Во-первых, здесь речь идет о воксельных ландшафтах,
которые вообщем-то не true-voxels. Трасировка лучей самый удобный способ
вывода вокселов, и он действительно аппаратно не реализуется, но вот
вывод группы вокселей на экран может быть заменен выводом нескольких
треугольников (речь идет только о heightfield ландшафтах), а это уже
можно перепоручить GPU. Реальных примеров полно начиная с демки glVox
от malkia и заканчивая terraVox'ом Чампандарта и демкой Андрея Сербы.
Во-вторых, есть реальные шансы реализовать трасировку лучей на GPU (не на
нынешнем поколении видюх конечно же). Причем трассировать лучи надо будет
от каждого пикселя, что снимает 4-dof ограничения. Преимущества GPU рендеринга
над CPU очевидны - параллельная обработка нескольких лучей и куча почти бесплатных
фич (интерполяция, выборка с билинейной фильтрацией, мип-маппинг...).
Так-что если скорость ядра GPU сравнится со скоростью современных CPU (а такое
не за горами) и программируемость конвеера позволит не задумыватся об
ограничениях шейдеров (в частности о размере, точности и ветвлении), думаю
можно ожидать появления "ускоряемых" вокселей

Я так понял, что воксели используются для ландшафтов.
А если мне надо например
чайник нарисовать,
или сферу,
или дерево,
или чьё-неибудь лицо,
то как мне быть?

Demiurg-HG
3d воксели скажем, если тебя на то потянуло. Или воксели в качестве displacement map-а.
Только не спрашивай как ето рисовать современнъм железом, я не знаю...

Zemedelec
Кстати не помню где... где то видел в инете шадер для нвидии кажется..
который делает виртуальный displacement bump. то есть фактически "воксельные ландшафты", натянутые на треугольники.
Вообще если подумать то на уровне железа это не так уж и сложно реализовать.. чтобы реальный дисплейсмент был (в пределах триангла) а не только тени.
Рельеф просто как будто "вдавлен". поэтому если смотреть вдоль треугольника то ниче не увидишь.
текстура рельефа хранится так что красный канал обозначает "глубину". синий канал - угол нормали вдоль U , зеленый - нормаль вдоль V. и получается все чудесно.
Там даже на одном примере сделали таким образом снимок бюста с 6 ракурсов. и натянули на бокс. и в результате получилась как бы моделька бюста... по типу голограммы

jm
Ну, вот, выдал все секреты нации :)
А mars.exe я заливал, насколько помню, не думал, что его кто-нить заметит.

Сделать 3D объект вокселами, элементарно. Это, тот-же битмап, но с тремя координатами, алгоритмы проекции те же. Только нужно ОЧЕНЬ много памяти, и нет аппаратной поддержки.

Смотрите, я его на javascript портировал:
http://jsfiddle.net/bdP9d/2/

Результат почти идентичен оригиналу, т.к. основан на дизассемблированном коде.

> 27 ноя. 2003

SoulSharer
Да ладно, человек крутоту сделал)

SoulSharer
ты балбес, человек решил новую тему не создавать, и апнул не тупым вопросом, а переписал демку, молодца он.

MihaiL
Ты невероятно крут. Эта демка в далеком 1994 году просто изменила мою жизнь. Я ее еще тогда пытался реализовать на Турбо Паскале. Правда получалось не очень. Ее секреты не давали мне покоя до сих пор. А тут прямо сквозь годы и расстояния добрый ангел MihaiL реализовал мою мечту. Спасибо!

Ivan77
> Я ее еще тогда пытался реализовать на Турбо Паскале
Был же в то время и на паскале аналог, название правда не помню. Ландшафт там вроде был цветной, но заметно грубее чем в mars, а исходник занимал что-то около двух страниц.