Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Формат карт и сцены(Программисты)
GAMEINATOR forums > > Архив
Neo][
FuckTER есть какие мысли?

Я так посидел подумал, а ведь не так всё просто.

В общем у нас будет свой формат моделей и свой формат карт.

Спросишь зачем свой формат моделей? Нам ведь ещё нужно хранить где-то физическую модель. Вот и предлагаю, всё вместе, с текстурой для данной модели(хотя вроде текстура уже есть даже в том же 3ds), хранить в одном файле.

Т.е. нам придётся ещё писать редактор физической модели. Он думаю нам пригодиться ещё и при регдолле.

Примерные наброски в конце поста.

По поводу формата карт будем писать в потоке.
Это даст нам возможность "данные об обстановке" представить в виде массива записей(типа TOurObject) примерно следующего вида:

Цитата
 
  TCoordinates = record
    x, y, z: Integer;
  end;

  TPhisycsParametrs = record
    Mass: Byte; // Просто для примера, надо будет смотреть
  end;

  TOurObject = record
    ID: Byte; // Уникальный ID объекта. Выбор типа данных обусловлен тем, что когда будем писать в файл меньше места будет занимать
    FileName: string; // Имя файла модели
    Coordinates: TCoordinates; // Координаты модели в игровом мире.
    PhysycsParametrs: TPhisycsParametrs; // Физические параметры объекта
  end;
FuckTER
Хм если учитывать что у меня тепература 40 и ангина =( ....
Короче сорри, тока выполз из кровати, весь день провалялся.
Спасибо за модератора. Пока буду восстанавливаться буду думать как это сформировать.
Насчет ID и общего файла для текстуры думаю неверно, во первых всякие ИД всегда быстро забываються и плохо воспринимаються, проще обекты именовать например так:
тип_название
а насчет общего файла это слишком громоздко, пойми делфи очень тормознутая штука сама по себе, если мы будем его нагружать большими монолитными файлами это будеи плохо, да и память будет тяжелее освобождать, хотя это вопрос спорный т.к. при раздельном формировании увеличиваеться фрагментацияя памяти, вобщем это надо будет думать.
я бы начал с простого, надо определиться каким макаром будем формировать ланшафт?
все зависит от того что мы хотим получить в итоге, т.к. к примеру карта высот проще обрабатываеться но она слишком(ИМХО)плавная и резких обрывов на ней не построиш,а координатная плоскость тяжелее обрабатываеться но зато с ней можно играть как захочешь.
Я считаю что главным тулом в редакторе ландшафтов должен быть тул как в редакторе фаркрая, типа выдавливания\вдавливания ландшафта, но его надо снабдить своими примочками чтоб не был такой зализанный.
Вобщем чет мозги не особо варят, как более-менее оклемаюсь вольюсь в работу
Neo][
Цитата
а насчет общего файла это слишком громоздко, пойми делфи очень тормознутая штука сама по себе, если мы будем его нагружать большими монолитными файлами это будеи плохо, да и память будет тяжелее освобождать, хотя это вопрос спорный т.к. при раздельном формировании увеличиваеться фрагментацияя памяти, вобщем это надо будет думать.



FuckTER, я довольно неплохо знаю Delphi, позволь с тобою не согласиться насчёт тормознутости, код генерируемый компилятором конечно медленнее кода генерируемого C++ компилятором, но во-первых не намного, а во-вторых всё зависит от реализации. Использование монолитных файлов предполагает работу с этим файлом при помощи файлового потока, что уже само по себе быстрее, чем использование типизированных файлов. А ведь ещё можно читать способами WinApi, которые думаю будут быстрыми.

Цитата
я бы начал с простого, надо определиться каким макаром будем формировать ланшафт?



FuckTER, нам надо то, что быстрее работает, а точнее то, что после того как загрузишь занимало мало памяти.

Точнее нет, не правильно. Я хотел сказать, что менее ресурсоёмкое, то и использовать.
OlegatoR
Я думаю что делать формат новый для моделй не надо да и мороки больше. А параметры физики хранить в отдельном конфиг-файле тесть к каждой модели будет свой конфиг с параметрами.
Neo][
Цитата
Я думаю что делать формат новый для моделй не надо да и мороки больше. А параметры физики хранить в отдельном конфиг-файле тесть к каждой модели будет свой конфиг с параметрами.


Одно дело хранить параметры физики(т.е. вес, плотность...), для каждого объекта, который у нас есть на уровне, а другое хранить физическую модель для объекта, допустим бочки(т.е. цилиндр с радиусом, высотой такими то, такими).

Но возможно нам и не понадобится хранить физическую модель(ведутся эксперименты по работе с модифицированным ODE)
OlegatoR
На ФТП залил ахив с Едитором. Вот кусок из РИДМИ
Цитата
На вкладке Objects я попытался реализовать загрузку объектов для расположения на карте - статические и динамические. Статичесике я думаю пнятно (возможно они и не нужны, их можно делать и в Максе вместе с поверхностью). Динамические - обьекты с физикой. Я пытался чтобы физика инициализировалась прямо в редакторе на этапе создании карты но они все время проваливались через ландшафт =) Я думаю легче просто сделать запись в файл параметров, что такой-то объект с физикой и потом при генерации карте (или как оно будет) уже будет орпеделяться или инициализироваться физика для этого объекта.
Я так прикинул, (и даже пытался сначала реализовать), что по сути наша карта - это файл со списком обектов и с параметрами для этих объектов (с координатами, путем к файлу и т.п) тоесть при "загрузке" карта "собирается" по параметрам - береться ландшафт(возможно уже с расставлеными статическими обектами - тоесть возможен вариант создания карт в 3Д-Максе а в нашем редакторе будт расставляться лищь физическте объекты)) и на нее (карту) "расставлаються" объекты (физические).
Кстати моделлерам нужно будет определяться с масштабом - чтобы в сцене использовать Scale как можно реже - неразбериха получается и вообще.
Тажке возникает вопрос - как будем делать небо, траву и сотльаные примочки - есть несколько идей - позже создадим отдельные темы в "технологиях".
Вообще еще есть проблемы с обектами в сцене - какие типы лучше, в каких случая нужны Дамми-кубики и т.п.
Пока все. Смотрите исходники.
З.Ы. В папке конфиг нужно чтобы были файлы, иначе будет ругацца.
В папке meshes - несколько моделек и один ландшафт - terrain.3ds
Также не щелкайте мышом по коричневой области если нету загруженых моделек! происходит ошибка и есои нету моделей приложение нужно перезапустить а если есть - выбрать модельку (объект)

Редактор идет как отдельное приложение - а вот модуль загрузки карты в Игре и в редакторе будет схожим (если не одинаковым) поэтому он будет как отдельный модуль
Екзешник кидаем в папку с нашим движком - И ДОБАВЛЯЕМ ДАНЫЕ В ПАПКУ DATA!!!(пару файлов и нескоко моделек)
Neo][
Цитата
и один ландшафт - terrain.3ds

Олег я так думаю, что ландшафт в 3ds нам не подойдёт, слишком медленно. Может TerrainRender и карта высот. Щас поэкспериментирую.
OlegatoR
Цитата
TerrainRender и карта высот.

И как оно и что оно? Слова вроде знакомые dry.gif
Neo][
Цитата(OlegatoR @ Oct 16 2006, 01:02)
Цитата
TerrainRender и карта высот.

И как оно и что оно? Слова вроде знакомые dry.gif

Смотри демку. Смысл в том, что карта высот храниться в BMP файле. Оттенком кодируется высота - от черного к белому. Но не заморачивайся пока, может надыбаю тот редактор.
OlegatoR
Цитата
может надыбаю тот редактор.

как же не заморачиваться? Работать ведь надо!
Цитата
может надыбаю тот редактор.

А может свой метод придумаем?
Neo][
Цитата
QUOTE
может надыбаю тот редактор.

как же не заморачиваться? Работать ведь надо!

Олег лучше придумай грамотную структуру классов, модулей для движка. То что я увидел у тебя в этой версии - это так полигон для опытов.

Цитата
QUOTE
может надыбаю тот редактор.

А может свой метод придумаем?

А зачем изобретать велосипед, если кто-то уже придумал алгоритм работы с ландшафтом. Ведь я же хочу взять у них не готовый редактор, а только формат файла.
OlegatoR
Цитата
классов, модулей для движка

...которые можно использовать и в редакторе и в движке? тоесть сделать классы для процесса создания/загрузки карты?
Neo][
Цитата
...которые можно использовать и в редакторе и в движке? тоесть сделать классы для процесса создания/загрузки карты?


Ну с форматом мы пока не совсем определились, сделай хороший каркас для проги, накидай интерфейс пока. Завтра допишу про вращение, перемещение объектов мышой.
OlegatoR
Насчет классов я еще это все туманно представляю потому что неизвестно как буим делать ландшафт, еще не сделно сохранение карты, загрузку карты и прочее - структура файлов карты, параметры, и т.п. Вобсчем буду думать и потихоньку работать.
Neo][
Цитата
как буим делать ландшафт

Не хотят делиться своими наработками, "братья разработчики".
OlegatoR, если не придумаешь способа лучше чем BMP файлы, то придётся делать BMP файлами.
Но опять же это отдаляет нас от концепции редактора. Ведь редактирование ландшафта и расстановка предметов должна по идее производиться в одной программе. Не будешь же ты делать рисование картинок.

Опять же как это реализовать? Т.е. уйти от BMP-шок. Заводить массив, в котором по координатам храняться значения высот, размерностью нашей карты? Неэкономично получается, сколько же памяти будет жрать этот массив при загрузке и обработке?

В принципе можно поробовать реализовать на основе вертексного представления ландшафта на основе TGLHeightField. Думаю для нас будет это самым оптимальным вариантом, но нельзя будет делать резкие обрывы.
Ну чё Олег скажешь?
OlegatoR
Цитата
Ну чё Олег скажешь?

Вот, блин, задачка dry.gif
Посмотрел я метод БМП - ацтой полный, ИМХО. Сидеть и рисовать карту - маразм.
А что если все-таки грузить 3дс файл с малым кол-вом полигонов? Там уж какой хочеь ландшафт можно сделать.
А насчет TGLHeightField - ка именно "сделать" эту карту? Сейчас занят немного другим (в плане программирования) поэтому нету времени разбираться - опиши вкратце - что оно из себя представляет.
З.Ы. Не забывай - нам на эту бренную землю еше текстуру надо будет натягивать smile.gif


Was added in 5 minutes 47 seconds:

Цитата
но нельзя будет делать резкие обрывы

у меня есть одна "нездоровая" идейка - обрывы делаем так: сначала не месте обрыва делаем плавную "вмятину" а острые края делаем 3дс-моделями - как гипоскартоном на стене - вроде настоящее, а на самом деле искуственно приделаное - надеюсь мысль понятна
OlegatoR
Паша, выложи плиз исходник редактора поверхности - ты его еще летом делал. - В теме Fan-game ссылки уже не рабочие.
Позырить охота
Neo][
Цитата
Посмотрел я метод БМП - ацтой полный, ИМХО. Сидеть и рисовать карту - маразм.

Согласен с тобой полностью. Ну да ладно рисовать, это в среднем 1 метр веса.

Цитата
А насчет TGLHeightField - ка именно "сделать" эту карту? Сейчас занят немного другим (в плане программирования) поэтому нету времени разбираться - опиши вкратце - что оно из себя представляет.

Я тебе могу дать даже исходник, попробуешь разобраться.
А вот по поводу твоего письма в принципе ты прав насчёт быстродействия, это мне приходиться использовать WinApi, учить ассемблер, чтобы поднять быстродействие. А в редакторе оно в принципе не нужно, но использование классов и т.д. ведёт не к повышению быстродействия. Если писать не оптимизируя, то этот код будет работать с такой же скоростью. А всё это направлено на повышение удобства, чтобы тебе самому не пришлось копаться в сотнях строчках кода, вместо десятков строчек.

Цитата
З.Ы. Не забывай - нам на эту бренную землю еше текстуру надо будет натягивать smile.gif

Точнее не натягивать а рисовать на поверхности определённой текстурой, опять в исходнике выше. Немного подправлю сегодня ночью и выложу.
Случаем не сможем с тобой сегодня в аське пообщаться, часов около 24:00 по Москве?

Цитата
QUOTE
но нельзя будет делать резкие обрывы

у меня есть одна "нездоровая" идейка - обрывы делаем так: сначала не месте обрыва делаем плавную "вмятину" а острые края делаем 3дс-моделями - как гипоскартоном на стене - вроде настоящее, а на самом деле искуственно приделаное - надеюсь мысль понятна

Мысль то понятна, а вот оно нам нужно? Зачем нам резкие обрывы?

Цитата
Паша, выложи плиз исходник редактора поверхности - ты его еще летом делал. - В теме Fan-game ссылки уже не рабочие.
Позырить охота

Смотри выше. Сегодня ночью или завтра с утра.
OlegatoR
Цитата
Случаем не сможем с тобой сегодня в аське пообщаться, часов около 24:00 по Москве?

В ближайшее время перейду на АДСЛ - тогда и пообсчаемся =)
Цитата
использование классов и т.д. ведёт не к повышению быстродействия

Не представляю как реализовать все это с использованием классов
Neo][
Цитата
QUOTE
использование классов и т.д. ведёт не к повышению быстродействия

Не представляю как реализовать все это с использованием классов

Главное основывайся на понятии, что отдельный класс это какой-то функционально законченный модуль. Т.е. если мыслить абстрактно, то это отдельная программа, которую можно использовать независимо где надо, проблем с построением при таком мышлении обычно не возникает.
Neo][
OlegatoR, в том, что я тебе скинул на ФТП. Есть руководство по GLScene, так вот в нём есть описание такого компонента как GLHeightTileFileHDS:

The source for height field HDS is .htf file. These files are created in [TODO]. This format is most suitable for really large terrains. Ground texture coordinates together with TileSize property are included in .htf file. TileSize of terrain renderer must be the same as TileSize in .htf file.

Что примерно звуччит как:
С помощью этого компонента можно грузить карту высот из файлов .htf. Хорош для больших пространств.
А грузить TerrainRender-ом, что облегчает работу, попробуй разобраться с этим форматом.
OlegatoR
Пасибо, но вот комментарии бы не помешали - быстрее бы разобрался
OlegatoR
Все таки мне кажеться, что карта у нас будет представлять собой файл со списком КФГ-файлов ИЛИ файл будет содержать только пути к мешам - а все остальные параметры будут храниться в нем же
Neo][
Цитата
Все таки мне кажеться, что карта у нас будет представлять собой файл со списком КФГ-файлов ИЛИ файл будет содержать только пути к мешам - а все остальные параметры будут храниться в нем же

OlegatoR, смотри первый пост этой темы по крайней мере: "Файл(Уровень)". Примерно так. С реализацией в коде прошу в тему редактора.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Форум IP.Board © 2001-2024 IPS, Inc.