Всем известно, что в космосе все очень большое (объекты и рассотяния).
Меня интересуют технологии реализации космических простанств.
Пока у меня только один вариант — делать все действительно большим.
Но возникают проблемы:
Глубина буфера не бесконечная,
На больших расстояниях проглючивает изображение
И как нарисовать звездное небо так, чтобы до него нельзя было долететь,
и в случае если звездное небо рисовать окружающей фигурой (кубик с текстуркой), то какого она должна быть размера?!!!
Кто-нить знает как такое вообще делается или может есть статьи на данную тему?
Здравствуйте, Ossto, Вы писали:
O>Всем известно, что в космосе все очень большое (объекты и рассотяния).
Есть немного.
O>Меня интересуют технологии реализации космических простанств. O>Пока у меня только один вариант — делать все действительно большим. O>Но возникают проблемы: O>Глубина буфера не бесконечная,
Большим все должно быть относительно. Скажем, если за единицу расстояния (например, метр) принять 0.001f, то 1.0f будет уже километр. 1000.0f — 1000 км. Никаких проблем с буфером не будет. Если конечно, не собираешься хранить описания всех объектов на многие сотни парсек . Если есть необходимость отслеживать и реализовывать поведение объектов на расстоянии многие миллионы километров, то уже надо шаманить, тут проблемы будут во всем, т.к. объектов в таком объеме немеряно и никакой и вычислительной мощности не хватит. Так лучше не делать, а рассматривать только ограниченное пространство небольшого размера (опять же относительно).
O>На больших расстояниях проглючивает изображение
Возможности глаза, да и аппаратуры не безграничны, поэтому можно определить некоторую границу и объекты, которые за нее выходят, просто не отображать. Например в современных играх эти объекты скрывают туманом. В космосе тумана нет, но есть звезды, поэтому если изображение объект соизмеримо с размером изображения звезд, то его также можно не рисовать.
O>И как нарисовать звездное небо так, чтобы до него нельзя было долететь,
Рисуется кубиком или шаром с текстурой. Рисуется перед выводом всей остальной графики с отключенным буфером глубины. Причем размеры куба или шара не обязательно должны быть большими. Достаточно взять длину ребра за 1.0f и при отображении неба помещать камеру в центр.
O>и в случае если звездное небо рисовать окружающей фигурой (кубик с текстуркой), то какого она должна быть размера?!!!
Я когда-то делал 128х128 на каждую грань. Имхо, это много. Достаточно 64x64, а то и 32х32. Там по субъективным ощущениям надо смотреть. Основная проблема, которую я не решил, была в том, чтобы не видно было щелей на стыках граней.
Я задумывался над этим. И вот до чего додумался: Фактически объекты бывают двух типов в космосе близкие и далекие: так если космический корабль дальше чего-то, то мы его вовсе не рисуем, а если планета или звезда — то рисуем ее уже совсем по другому, чем если бы она была близко. Т.е. планета вдалеке — это шарик, а планета вблизи — это поверхность земли под днищем. Дык вот эти два типа объектов можно рисовать, используя разные системы координат.
Т.е. каждый объект имеет координаты в "большой" системе координат, где счет идет на астрономические единицы и далекие объекты рисуются, используя именно эту систему координат. Кроме того, объект имеет еще и координаты в "малой" системе координат, которые есть уточнение координат относительно координат в "большой" системе. Близкие объхекты рисуются именно в этой системе. А близкие — это те, что в большой системе находятся в той же точке.
O> Кто-нить знает как такое вообще делается или может есть статьи на данную тему?
Есть пример на OpenGL моделирующий солнечную систему.
Почти все, что ты хочешь там есть.
Откуда брал не помню. Называется GLDemo.
Начало хедера
The Universe Development Kit
Copyright (C) 2000 Sean O'Neil
s_p_oneil@hotmail.com
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Readme
GLDemo readme
Keyboard commands (toggle NumLock if keypad keys don't work):
keypad 2, 4, 6, 8 — turn camera
keypad 7, 9 — roll camera
keypad +, — — adjust error threshold to increase/decrease detail
w, s, a, d — thrust forward, reverse, left, and right
Ctrl — hold down for 100x thrust
spacebar — full stop
f — toggle fullscreen/windowed mode
g — toggle shading mode (Gourad/flat)
p — toggle polygon mode (fill/edge)
t — toggle texture maps (on/off)
i — toggle mesh & planet info (on/off)
u — toggle mesh updates (on/off)
Helpful hints:
1) The first time you run this demo, hold down Ctrl+w to fly to the planet as
close as you can, then hit the spacebar to stop. Collision detection has been
implemented with the planetary bodies, but it is not 4D. So if you go too
fast, you might fly right through the planet. Once you get close enough, use
the unaccelerated thrusters to fly over the planet's surface, looking at the
coastlines and mountains.
2) This project was built with Visual C++ 6.0. You should be able to build it
with 5.0 as well, but a new project file may need to be created. If so, it
shouldn't be that difficult to create. Other than OpenGL32.lib and GLU32.lib,
I'm linking nothing but standard Windows libraries.
3) I've written a simple memory manager which allocates a fixed block of
memory. If you increase the detail with the + key too much, the program may
crash. You can get rid of this by commenting out the define of USE_ALLOCATOR
in ROAMSphere.h and rebuilding.
4) The CGameEngine constructor initializes the planet, the moon, their
textures, and the camera position. Changing some of these initialization
parameters is a good starting place for experimentation.
5) There is a commented-out RenderFrame() function in GameEngine.cpp. You can
use it in place of the current one to quickly draw 2D textures to the screen
that you've generated.
Здравствуйте, HeaveN, Вы писали:
HN>Большим все должно быть относительно. Скажем, если за единицу расстояния (например, метр) принять 0.001f, то 1.0f будет уже километр. 1000.0f — 1000 км. Никаких проблем с буфером не будет. Если конечно, не собираешься хранить описания всех объектов на многие сотни парсек . Если есть необходимость отслеживать и реализовывать поведение объектов на расстоянии многие миллионы километров, то уже надо шаманить, тут проблемы будут во всем, т.к. объектов в таком объеме немеряно и никакой и вычислительной мощности не хватит. Так лучше не делать, а рассматривать только ограниченное пространство небольшого размера (опять же относительно).
да но у камеры есть вполне определенные размеры и разницу между кубиком с длиной грани 10.0f и 100.0f будет заметна.
То есть если рассматривать планеты то будет бросаться в глаза какое-то несоответствие масштабов. Проверял.
Хотя это может и субъективно...
HN>Возможности глаза, да и аппаратуры не безграничны, поэтому можно определить некоторую границу и объекты, которые за нее выходят, просто не отображать. Например в современных играх эти объекты скрывают туманом. В космосе тумана нет, но есть звезды, поэтому если изображение объект соизмеримо с размером изображения звезд, то его также можно не рисовать.
по поводу проглючки изображения... на больших расстояниях (сфера, сделанная из quadratic), так вот получается какой-то наплыв текстуры
Здравствуйте, Андрей Галюзин, Вы писали:
O>> Кто-нить знает как такое вообще делается или может есть статьи на данную тему?
АГ>Есть пример на OpenGL моделирующий солнечную систему. АГ>Почти все, что ты хочешь там есть. АГ>Откуда брал не помню. Называется GLDemo.
АГ>Начало хедера АГ>
АГ> The Universe Development Kit
АГ> Copyright (C) 2000 Sean O'Neil
АГ> s_p_oneil@hotmail.com
(...)
Очень похоже, что это и есть код к той самой "Процедурной вселенной".
Здравствуйте, HeaveN, Вы писали:
О
Космических масштабы в OpenGL
У меня вопрос по отдельной звездочке (точке) Как задать яркость 3d точке
Имею 3-х мерный массив данных. Решил отобразить его с помощью OpenGl
Просто задать каждой точке яркость пропорционально соответствующего данного в массиве.
Координаты рисую. Точки тоже рисую. А яркость (освещенность) не нашел как задать отдельно
каждой точке. Подскажите.
HN>Здравствуйте, Ossto, Вы писали:
O>>Всем известно, что в космосе все очень большое (объекты и рассотяния).
HN>Есть немного.
O>>Меня интересуют технологии реализации космических простанств. O>>Пока у меня только один вариант — делать все действительно большим. O>>Но возникают проблемы: O>>Глубина буфера не бесконечная,
HN>Большим все должно быть относительно. Скажем, если за единицу расстояния (например, метр) принять 0.001f, то 1.0f будет уже километр. 1000.0f — 1000 км. Никаких проблем с буфером не будет. Если конечно, не собираешься хранить описания всех объектов на многие сотни парсек . Если есть необходимость отслеживать и реализовывать поведение объектов на расстоянии многие миллионы километров, то уже надо шаманить, тут проблемы будут во всем, т.к. объектов в таком объеме немеряно и никакой и вычислительной мощности не хватит. Так лучше не делать, а рассматривать только ограниченное пространство небольшого размера (опять же относительно).
O>>На больших расстояниях проглючивает изображение
HN>Возможности глаза, да и аппаратуры не безграничны, поэтому можно определить некоторую границу и объекты, которые за нее выходят, просто не отображать. Например в современных играх эти объекты скрывают туманом. В космосе тумана нет, но есть звезды, поэтому если изображение объект соизмеримо с размером изображения звезд, то его также можно не рисовать.
O>>И как нарисовать звездное небо так, чтобы до него нельзя было долететь,
HN>Рисуется кубиком или шаром с текстурой. Рисуется перед выводом всей остальной графики с отключенным буфером глубины. Причем размеры куба или шара не обязательно должны быть большими. Достаточно взять длину ребра за 1.0f и при отображении неба помещать камеру в центр.
O>>и в случае если звездное небо рисовать окружающей фигурой (кубик с текстуркой), то какого она должна быть размера?!!!
HN>Я когда-то делал 128х128 на каждую грань. Имхо, это много. Достаточно 64x64, а то и 32х32. Там по субъективным ощущениям надо смотреть. Основная проблема, которую я не решил, была в том, чтобы не видно было щелей на стыках граней.
. Если есть необходимость отслеживать и реализовывать поведение объектов на расстоянии многие миллионы километров, то уже надо шаманить, тут проблемы будут во всем, т.к. объектов в таком объеме немеряно и никакой и вычислительной мощности не хватит. Так лучше не делать, а рассматривать только ограниченное пространство небольшого размера (опять же относительно).
"Вы писали:" -- лишнее. Сорри.
