Форум Херсона. Форум Херсонской молодежи.

Дополнительные опции
Другое Автоматически вставлять ссылки

12.09.2010 16:47

Marchello

И еще чуть-чуть уже с игры:
Вложение 140701
Вложение 140702
Боты друг друга валят:
Вложение 140703
Сам бот, нарисовал как смог

Вложение 140704

12.09.2010 16:43

Marchello

Дальше:
Вложение 140696
Вложение 140697
Вложение 140698
Вложение 140699
Вложение 140700

12.09.2010 16:40

Marchello

Вот решил показать немного скринов со своего "движка".
Все как всегда, вся программная часть (С++ & shaders) исключительно моя, бездарные модели (кроме динозавра) - тоже моих рук дело в 3ds max, текстуры - украдены откуда только можно

На скринах можно видеть: Deferred Shading (как основа движка) + bump mapping & specular lighting, Shadow Maps (для точечного источника света юзаются cube maps), SSAO (еще нужно улучшать..), Bloom, Distortion.
Разные материалы:
Вложение 140691
Вложение 140692
Кубик слева - преломляет свет.
Вложение 140693
Взгляд изнутри преломляющего кубика:
Вложение 140694
Вложение 140695

23.08.2010 23:08

lucky_DS

Вдвоем с моделлером
через аську

23.08.2010 20:09

Rammf

Цитата:

Сообщение от lucky_DS

я таки дописал игру и она издана

Вложение 139404
http://www.buka.ru/cgi-bin/show.pl?id=489

В одиночку?

23.08.2010 18:12

firma

Цитата:

Сообщение от lucky_DS

я таки дописал игру и она издана

Вложение 139404
http://www.buka.ru/cgi-bin/show.pl?id=489

Есть Crack? погамать

23.08.2010 17:26

lucky_DS

я таки дописал игру и она издана

Вложение 139404
http://www.buka.ru/cgi-bin/show.pl?id=489

24.12.2009 13:53

Ecstrazzz

Цитата:

Сообщение от Keller

а я слышал что есть какоето подразделение GSC в херсоне, мож конечно и враки, но всё-же...

Это не подразделение ЖСК, а команда которая занималась модостроем, и дошла до сотрудничества с ЖСК.. а конкретнее рисовала для них мультиплеерные уровни.. на некоторых из карт проводился чемпионат по СНГ.. более подробно http://kst.clan.su/...

24.12.2009 10:38

Taki

А что скажите насчёт такого движка, как Unity. Интересно узнать мнение знающих людей.Сам начал его разбирать недавно, первый раз когда посмотрел их 3D демку в браузере про тропический остров немного ошалел. Мощная технология.
Вот небольшое описание того что есть:
Вложение 122683
Если кому интересно, вот несколько демок (находятся в нашей сети, инет не нужен) Unity Live Demo
Для просмотра требуется вот этот плагин Unity Web Player.

P.S.: Буду не оригинален

, есть пара идей насчёт проектов на данном движке

09.11.2009 15:59

Marchello

Цитата:

Сообщение от Honer

http://www.ogre3d.org/download/sdk
SDK условно бесплатный, есть примеры и документация вменяемая. Сам работаю с SDK.

С готовыми движками иметь дело не столь интересно. Вот свой писать - другое дело. Понятно, что свой - это будет там 5-15% от того же Ogre,
но это будет свой! Так понять как работает видеокарта и вообще как работает 3D (и движки в общем) - намного больше шансов.
Та и вообще писать самому с нуля - тут больше интересен не результат, а сам процесс (если конечно это типа хобби, а не работа).
Так я могу гордо сказать

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

09.11.2009 10:28

Honer

Features

Features Productivity features

Simple, easy to use OO interface designed to minimise the effort required to render 3D scenes, and to be independent of 3D implementation i.e. Direct3D/OpenGL.
Extensible example framework makes getting your application running is quick and simple
Common requirements like render state management, spatial culling, dealing with transparency are done for you automatically saving you valuable time
Clean, uncluttered design and full documentation of all engine classes
Proven, stable engine used in several commercial products

Platform & 3D API support

Direct3D and OpenGL support
Windows (all major versions), Linux and Mac OSX support
Builds on Visual C++ and Code::Blocks on Windows
Builds on gcc 3+ on Linux / Mac OSX (using XCode)

Material / Shader support

Powerful material declaration language allows you to maintain material assets outside of your code
Supports vertex and fragment programs (shaders), both low-level programs written in assembler, and high-level programs written in Cg, DirectX9 HLSL, or GLSL and provides automatic support for many commonly bound constant parameters like worldview matrices, light state information, object space eye position etc
Supports the complete range of fixed function operations such as multitexture and multipass blending, texture coordinate generation and modification, independent colour and alpha operations for non-programmable hardware or for lower cost materials
Multiple pass effects, with pass iteration if required for the closest ‘n’ lights
Support for multiple material techniques means you can design in alternative effects for a wide range of cards and OGRE automatically uses the best one supported
Material LOD support; your materials can reduce in cost as the objects using them get further away
Load textures from PNG, JPEG, TGA, BMP or DDS files, including unusual formats like 1D textures, volumetric textures, cubemaps and compressed textures (DXT/S3TC)
Textures can be provided and updated in realtime by plugins, for example a video feed
Easy to use projective texturing support

Meshes

Flexible mesh data formats accepted, separation of the concepts of vertex buffers, index buffers, vertex declarations and buffer mappings
Biquadric Bezier patches for curved surfaces
Progressive meshes (LOD), manual or automatically generated
Static geometry batcher

Animation

Sophisticated skeletal animation support
- blending of multiple animations with variable weights
- variable/multiple bone weight skinning
- software and hardware-accelerated skinning pipelines with intelligent buffer sharing
- manual bone control
- Configurable interpolation modes, accuracy vs speed tradeoffs
Flexible shape animation support
- Morph animation for legacy applications where you wish to perform simple linear blends between shape snapshots
- Pose animation for modern shape animation, allowing you to blend many poses at variable weights along a timeline, for example expression / mouth shapes to perform facial animation
- Both techniques can be implemented in hardware and software depending on hardware support
Animation of SceneNodes for camera paths and similar techniques, using spline interpolation where needed
Generic animation tracks can accept pluggable object adaptors to enable you to animate any parameter of any object over time

Scene Features

Highly customisable, flexible scene management, not tied to any single scene type. Use predefined classes for scene organisation if they suit or plug in your own subclass to gain full control over the scene organisation
Several example plugins demonstrate various ways of handling the scene specific to a particular type of layout (e.g. BSP, Octree)
Hierarchical scene graph; nodes allow objects to be attached to each other and follow each others movements, articulated structures etc
Multiple shadow rendering techniques, both modulative and additive techniques, stencil and texture based, each highly configurable and taking full advantage of any hardware acceleration available.
Scene querying features

Special Effects

Compositor system, allowing for full-screen postprocessing effects to be defined easily, via scripts if desired
Particle Systems, including easily extensible emitters, affectors and renderers (customisable through plugins). Systems can be defined in text scripts for easy tweaking. Automatic use of particle pooling for maximum performance
Support for skyboxes, skyplanes and skydomes, very easy to use
Billboarding for sprite graphics
Ribbon trails
Transparent objects automatically managed (rendering order & depth buffer settings all set up for you)

Misc features

Common resource infrastructure for memory management and loading from archives (ZIP, PK3)
Flexible plugin architecture allows engine to be extended without recompilation
‘Controllers’ allow you to easily organise derived values between objects e.g. changing the colour of a ship based on shields left
Debugging memory manager for identifying memory leaks
ReferenceAppLayer provides an example of how to combine OGRE with other libraries, for example ODE for collision & physics
XMLConverter to convert efficient runtime binary formats to/from XML for interchange or editing

http://www.ogre3d.org/download/sdk
SDK условно бесплатный, есть примеры и документация вменяемая. Сам работаю с SDK.

07.11.2009 20:14

Marchello

Цитата:

Сообщение от Marchello

deferred shading (я в своей будущей игре #2 тож этот подход юзаю)

Чтобы не быть голословным, покажу пару скринов. Конечно это не сравнимо с UE3

(учитывая мои бездарные навыки в рисовании, так как этой ерундой тож самому приходится заниматься).
Вложение 119335
...
Вложение 119336

07.11.2009 19:55

Marchello

Цитата:

Сообщение от ustas

UDK is Unreal Engine 3
http://www.udk.com/index.html
Experience the power and potential of Unreal Engine 3. Create amazing games, lifelike scenes and fantastic worlds... for free.
Марчело что скажешь? Каков подарок от разработчиков, твоя оценка.
Есть пару тем, в личку если не лень и есть спортивный интерес.

Та оценить сходу сложно

Но интересно конечно.. Если бы были исходники самого движка - было бы реально интересно! Хотя там наверное есть чуток (в основном *.h файлы

)
ИМХО чтобы это все дело заюзать, нужно доки читать не один день наверное (и учить Unreal script) )) хотя я даже пока не знаю что там (в самом UDK).
Я слышал Тим Свинней уже взялся за Unreal Engine 4, видать дела пошли хорошо, и они решили поделиться дев-китом.
Еще интересно, что именно скрывается за надписью for free, неужто можно в коммерческих целях юзать?
А, вот нашел там Licensing, правда многа букв, но общий смысл понятен, деньги в таком случае платить все равно нужно будет (но все довольно честно).
Ну что сказать, наверное мое мнение (пока поверхностное) будет примерно следующим:
- для самообразования нет смысла юзать, ну разве что для фана.
В общем, для "поглазеть и побаловаться" - можно.
- для чего-то серъезного (вплоть до реальной конечной игры) -
как бы можно, но не реально. Сейчас уровень современный игр очень высокий. Я недавно прошел Borderlands (тож на UE3), и в конце глянул на тирты, ёлки-палки, игру делали наверное человек 300! (и это при готовом движке).
Но тем не менее скачать интересно, так как я могу и ошибаться, посмореть на труд профессионалов всегда интересно и полезно. (правда с моим инетом качаться будет ой долго...).
Кстати, на сколько я знаю UE3 юзает deferred shading (я в своей будущей игре #2 тож этот подход юзаю), интересно пойдут ли они дальше в этом направлении?

07.11.2009 15:52

ustas

08.03.2008 22:18

lucky_DS

Я немножко пишу в 3д
Сделал 7 скринсейверов (коммерческих)
вот пара последних, самых удачных:
http://7art-screensavers.com/alien-c...eensaver.shtml
http://www.screensworld.com/index.ph...id=18&Itemid=1
десяток небольших игр (любительских)
вот ссыла на самую первую 4-ех летней давности:
http://wildboar.nm.ru
Законченная еще одна - SmartBots игра для программирования ИИ. Пишешь боту (авто с пушкой и ракетами) искусственный интеллект на бейсико-подобном скрипте, и запускаешь ботов в бой. Все в 3д. Проводили чемпионаты, была компания примерно чел 30, потом как-то все заглохло.
Еще есть с десяток техно-дем для самых разных игр от шутера до стратегии, но заброшено по причине отсутствия графики.
Сейчас пытаюсь сделать аркадную гонку
вот скрины скринсейвера, и некоторых игр:

01.03.2008 07:39

Absent

в 2000 писали МУД очень жырный в плане фичь...
Ядро вЫписали, бизнеслогику, тексты и штук 9 локаций разного уровня зафиченности...
но потом поразбредались по киевАм...

потом пробовали наваять 3Д стратежку в команде.
Задуманные фишки до сих пор не реализованы не в одной известной мне из обзоров игр.

...

время шло, и я стал серверным программистом.
воттакие вот мои 5 копеек в тему.

25.02.2008 21:09

Taki

Спасибо за ответ.

25.02.2008 17:54

Marchello

Цитата:

Сообщение от Taki

Ну и вопрос по игрострою. Анимацию ботов ты делал программно или анимация делалась в 3Д пакете, а потом посредством плагина экспортировалась в игру. И если можно про процесс анимации в игрострое "в двух словах".

Значит так. Небольшой секрет - в моей игре анимации, как таковой - нет ;)
Под анимацией - я понимаю, например, скелетную анимацию - это
система "костей" и их преобразований.
Модели я делал в максе, а потом экспортил их через свой самописный
плагин в свой формат. Анимацию мой формат (и плагин) не поддерживает.
Один момент - я все абсолютно рисовал сам, а так как я не художник -
меня это занятие напрягает немного...
И главная причина, по которой в моей игре нет анимации - потому
что в максе я даже не знаю как её заюзать. Но заюзать - это одно,
а нужно ж еще и заанимировать, там понастраивать всякие параметры
и т.д. - этим заниматься я не хочу и не умею (нужно много времени,
умения/знания, опыта что ли), поэтому на анимацию я забил.
Да и видел моих ботов )) там и анимацию некуда прикручивать, так
как, опять таки - все нужно рисовать/моделить.
А нарисоать (~красиво) персонажа, затекстурить его, заанимировать
все нужные движения, потом это все не криво заэкспортить - это
целое дело...
Все что у меня движеться в игре - это запрограммированые движения,
то есть, позиция/угол/скорость/траэктория - расчитываются
в реал-тайме по определенным формулам. Там в одной из моих демок
можно увидеть листок конопли из частичек - все расчитывается
по длинющей формуле (в полярной системе координат) - взятой
в инете (типа вставте в МатКад - и он вам выдаст конопляный лист )) ).
Так что, ориентируясь в математике, можно частично анимацию
организовать прямо в коде.
А движение ботов (изменение самих координат) выполняет система ИИ

25.02.2008 16:09

Taki

Классная тема, за что отдельная благодарность Марчело, и за инфу про XNA (прсто и доходчиво.)
Ну и вопрос по игрострою. Анимацию ботов ты делал программно или анимация делалась в 3Д пакете, а потом посредством плагина экспортировалась в игру. И если можно про процесс анимации в игрострое "в двух словах".

24.02.2008 19:49

Marchello

Цитата:

Сообщение от Aurum

The static methods defined on the Marshal class are essential to working with unmanaged code. Most methods defined in this class are typically used by developers who need to provide a bridge between the managed and unmanaged programming models.

Та не, смысл не в этом.
Я имею в виду, если уже писать на шарпе - то все будет на шарпе,
никаких извратов с unmanaged code. Даже в многих книгах говорят:
"старайтесь мол как можно меньше юзать unmanaged stuff, так как
unmanaged - это зло (тем более в managed коде), бла-бла".
А если уж есть потребность в unmanaged коде - я делаю так:
- unmanaged код - в native DLL (например звуковая либа)
- Потом на Managed C++ пишем врапер-интерфейс, и его тоже в
DLL (только уже managed).
- и юзаем уже в том же шарпе эту вторую DLL.
Кстати, вот таким вот образом можно юзать некоторые граф. движки
в managed среде (C#), то есть, ядро - native code, и через C# - сам
интерфейс.

А на счет отсутствия memcpy в шарпе - не имелось в виду, юзать
её unmanaged вариант, а то что эта вот безопасность (работа с
памятью и т.д.) в managed среде - на данный момент - в урон производительности.

24.02.2008 19:15

Aurum

Цитата:

Сообщение от Marchello

Нет прямого доступа
к памяти, и почти не управляемый (программистом) garbage collector.
Например, есть у меня массив структур - и нужно его скопировать
в другой массив - на С/С++ - одна комманда memcpy - один кусок
памяти копирует в другой, а на С# так просто не выйдет, нужно
перебирать массив и делать переприсвоение вручную

юзай маршалинг.. выноси что угудно(любые типы, структуры в неуправляемую область памяти.. динамические, статические и т.д.) я думаю о memcpy забудешь быстро.. так как возможностей там оч много.. если я правельно понял о чём речь ))))
The static methods defined on the Marshal class are essential to working with unmanaged code. Most methods defined in this class are typically used by developers who need to provide a bridge between the managed and unmanaged programming models.

20.02.2008 23:21

Joey[CJ]

Цитата:

Сообщение от Marchello

Ну что сказать, в кратце - ничего плохого, но и не много хорошего...

Блин, обломался на средине спать хочется :( Завтра дочитаю

20.02.2008 19:43

ustas

Спасибо за полноценную лекцию по запрошенной тематике. В том что это вариант для разработки простых решений абсолютно согласен. Еще раз спасибо )).

20.02.2008 14:34

Marchello

Цитата:

Сообщение от ustas

Марчело, ты как местный гуру гэйм депелопмента скажи что за зверь этот XNA Game Studio от Microsoft, насколько распостранен девелопмент игровой с его использованием. Еще кто знает делитесь информацией интересно будет почитать.

Ну что сказать, в кратце - ничего плохого, но и не много хорошего.
Начнем с того что XNA - это C#, а С# - управляемый язык. Следствие
этого - ниже производительность чем native языков. Нет прямого доступа
к памяти, и почти не управляемый (программистом) garbage collector.
Например, есть у меня массив структур - и нужно его скопировать
в другой массив - на С/С++ - одна комманда memcpy - один кусок
памяти копирует в другой, а на С# так просто не выйдет, нужно
перебирать массив и делать переприсвоение вручную. Может кто-то
скажет "У Array есть метод CopyTo" - неправильно, это будет не
глубокая копия. Или, например, самый распространенный тип в игре -
3D вектор - делать его как value type или как reference type ?
А хрен его знает. Если value type - при передаче в функции как
параметр будет происходить копирование данных (лишнее) - плохо,
а если как reference type - нужно будет динамически выделять память
из managed кучи - это тоже плохо. Ну и всё в этом роде.
Чесно говоря, не раз приходилось убеждаться в плохой
производительности managed кода вовсе не в рамках игр и т.п.
Не везде конечно, но есть bottle neck-и...
Если вооружиться С++ - у программера больше свободы.
Он контролирует все, начиная от регистров, asm вставок заканчивая
своими менеджерами памяти. Я имею практику как C# так и C++,
C# удобнее, проще, многое написано уже до/для тебя - .NET Framework,
на С++ все наоборот, зато полный контроль, полная свобода действий,
и ощущаешь себя true програмером ;)
Но не будем устраивать holy war между языками, ведь речь собственно не об этом. Оба языка, даже не языка а "native vs managed" - имеют
свои преимущества и недостатки...
Так вот, XNA - это, грубо говоря, managed обёртка над DirectX.
То есть, юзая XNA - последний в свою очередь юзает DX.
С одной стороны лучше работать без "посредников" - с другой -
с посредниками проще, удобней, быстрей.
Многие запускают примерно одинаковые демки на шарпе (XNA) и на
С++ - говорят "смотрите, fps одинаковый!" но это ошибочно,
так как в этом случае простая посылка данных на отрисовку будет
работать одинаково, другое дело полноценная игра. Помню как сказал
Tim Sweeney - главный прогер линейки Unreal - простые люди даже не
подозревают на сколько мощны сегодняшние процессоры, и как много
расчетов они могут сделать в еденицу времени. В полноценной игре -
расчетов огромнейшее количество. Справиться ли C# с таким количеством ? (за минимум времени).
В общем, вывод такой, если вы не собираетесь писать игру аля Unreal3 - XNA вам в помощь. И еще C# не стоит на месте, там придумывают
новые технологии для JIT компилятора и т.д. так что возможно
когда-то managed code сравняется в производительности c native кодом.
Также многие true программеры не любят "чёрных ящиков" - коим
является и XNA и .net framework в целом, весь нужный код пишут сами
и под себя, поэтому они по прежнему выбирают native код.
Вы не подумайте что я намерено пытаюсь "унижать" XNA и managed подход,
Microsoft двигает эту технологию вперед, а вот будет ли она
понастоящему востребована или нет, это другой вопрос...
Managed код прекрасно находит себе применение в других приложениях,
а дойдет ли дело до больших реальных игр - я не знаю.
Еще играет роль количество наработок, например реальные
разработчики игр имеют огромную базу своих наработок/движков,
просто классов/кусков кода. Они же все не бросят и не начнут
заново переписывать под XNA/C# - смысла нету, так как и их
движки и тот же XNA юзают тот же DirectX/OpenGL.
Если бы у нас были реальные геймдев конторы - туда бы не брали вас
если у вас в резюме будет написано C#/XNA, ну разве что редакторы
какие писать на C#-WinForms.
В общем для себя, в удовольствие - XNA пожалуйста, а для
промышленных масштабов - не покатит (пока что).
Я помню, видел сравнения кода на каком-то dark/blitz3D basic-е
и на С++. Пару строчек на бейсике - равнялись двум десяткам
строчек на С++, это означает что в бейсике довольно много работы
происходит "за кулисами" - новичков это более чем устраивало,
но профи - на это смотерть не могли ;)
В общем, когда я увижу Unreal4 (образно), а не гоночки-шмоночки, на
XNA/C# - вот тогда будет о чем реально спорить и думать...
Если решил изучать XNA - изучай, это будет не менее интересно чем другое!

20.02.2008 10:43

wouldnt_even

Цитата:

Сообщение от Rammf

Товарисч а поделиться теоретическим материалом можеш? Книги, хелпы, учебники и пр.

вот например : http://rustud.ru/matematika/gl1/

20.02.2008 08:52

ustas

17.02.2008 17:16

ustas

Марчела маладца, одназначна.

17.02.2008 15:10

Debian

прикольно, мне понравилось

17.02.2008 14:04

pingwinator

Цитата:

Сообщение от Marchello

Доступ я не убирал.
Возможно комп был выключен, или лаги сети...

Так, теперь ответ pingwinatorу.
Так как мне было нечего делать

я написал примерно то что тебе
нужно. Но только примерно.
Код - максимально упрощен, и написан за 1,5 часа, так что искать
в нем глубокие смыслы ООП и т.д. - не нужно.
Код можно разделить (образно) на пару частей:
- создание окна (на WinAPI)
- инициализация Direct3D (создание девайса), и всего остального.
- гланый цикл (в методе Run), и отрисовка.
В коде стоят кое-какие жалкие коментарии.
Код на С++ (я надеюсь другого не ожидали )) )

Модель шара загружается из файла, т.к. мне было впадло писать
функцию генерации шара из треугольников.

Это наиболее упрощенный вариант, то есть без текстур и без освещения.
Кстати, можете поупрожняться в математике прикрутив сюда
освещение. Это делается довольно просто (в смысле самое
примитивное освещение) - в структуре TVertex - есть поля nx, ny, nz -
это нормаль вершины.
Берем точку источника света за 0, 0, 0 - тут как раз находится
солнце, затем циклом бежим по вершинам планет и подсчитываем
коэфициент освещенности: k = N * L
где N - вектор нормали (nx, ny, nz)
L - вектор от источника света до позиции вершины - вычисляется как
нормализировать([позиция вершины] - [позици источника])
и '*' - это скалярное умножение (dot product) - это и будет
коэфициент освещенности.
тогда цвет вершины будет:
color = M_RGB((int)255.0f*k, (int)255.0f*k, (int)255.0f*k);

Код и exe лежит в архиве, чтобы скомпилить код нужен DirectX SDK
(у меня на ФТП есть).

мда - сильно, как буду в винде - пойду разбирать

Цитата:

Сообщение от Marchello

Под Линукс... Вообще под Линукс - OpenGL, но для отрезка
думаю не стоит его дергать. Я програмил на Kylix - там будет попроще,
есть Canvas - и вперед, то есть как в винде на Делфи/Билдере.

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

17.02.2008 13:57

Marchello

В этой теме более 30 ответов(а). Нажмите здесь, чтобы перезагрузить эту тему.

Форум Херсона. Форум Херсонской молодежи, флейм, фотографии Херсона, политика в Херсоне, сетевой форум, сети Херсона