Jump to content

Recommended Posts

post-12933-0-85422600-1351201591_thumb.jpg

 

post-12933-0-86931500-1351374966_thumb.jpg

 

post-12933-0-69059200-1351374967_thumb.jpg

Edited by ANRI
  • Upvote 3

Share this post


Link to post
Share on other sites

4. используя геймпак 2002, применяя правку acm-кода.

Мой любимый способ. Для быстрой правки ASM был написан простенький парсер, в котором можно выбрать номер слоя, убрать тени и выкос автогена.

Share this post


Link to post
Share on other sites

Мой любимый способ. Для быстрой правки ASM был написан простенький парсер, в котором можно выбрать номер слоя, убрать тени и выкос автогена.

Может, стоить выложить?

Хотя рука уже набита за тысячи раз правки АСМа, но, может, и пригодится в будущем.

Share this post


Link to post
Share on other sites

Может, стоить выложить?

Хотя рука уже набита за тысячи раз правки АСМа, но, может, и пригодится в будущем.

Женя,что то мне подсказывает,что этот вариант,в частности с выбором слоя не совсем подойдёт.В частности и тебе! Уже давно все укоренились во мнении,что всё "плоское" лучше гнать одной сценой из гмакс. Не отдельными слоями. Поэтому этот вариант лучше решать ещё в "зародыше". При построении в гмасе. А именно выручаясь наименованием текстур,и другими хитростями,при наложении этих слоёв,повторюсь,ещё в гмаксовской сцене.Совсем недавно,открыл для себя ещё один гмаксовский секретик в назначении требуемой последовательности такого наложения. Если интересует могу поделиться.Правильно- не правильно,-но работает.

Edited by Marlboro

Share this post


Link to post
Share on other sites

...всё "плоское" лучше гнать одной сценой из гмакс. Не отдельными слоями.

Интересно, какие же преимущества такого подхода по сравнению с традиционным? Что мешает в финале объединить все слои в 1 бгл, как описано здесь, во второй части:

http://fsdeveloper.com/wiki/index.php?title=Ground_polygons_%28ASM_tweak%29

Share this post


Link to post
Share on other sites

Ребята, сперва делается ОСНОВА, ее роль вполне может выполнить тот-же полигон подложки,

потом накладываем на него все детали послойно.

Но как бы мы не старались, иногда бывают ошибки и промашки в организации порядка слоев,

в этом случае создаем новый проект и поочередно, слой за слоем, в нужном порядке импортируем

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

 

Это только теория, на практике я проверял это только однажды, с целью освоения этой методики,

а вот Саша (Phemmer) этот принцип использует в данный момент при создании Шереметьево,

Может он заметит наши волнения по этому поводу? :)

Share this post


Link to post
Share on other sites

Смею подметить об одном важном нюансе данной технологии "расслоевки"... Фишка этого способа в четком именовании текстур.То есть на пратике это может выглядеть примерно так,например самый нижний слой асфальта,применяем к нему текстуру типа "А_asfalt",следующим слоем пускай пойдет детализация,обзавем текстуру уже "B_detal",третьим слоем будет например грязь,к ней соответственно "С_Dirt",в итоге у нас получится иерархия слоев в алфавитном порядке,можно замутить и в цифровом порядке. Компилим 2002-м геймпаком общей массой,и в АСМе все слои выстроятся в нужном порядке,в нашем примере будет A/B/C... И еще есть один моментик....если в Gmaxe к материалу применена прозрачность,то при компиляции порядок нарушается.Могу ошибаться,но кажется слой с прозрачностью становится приоритетным и становится в "голову состава"...

Сергей прав,это идея Саши (Phemmer),он ее и поведал,за что ему Большое спасибо!!!

Edited by icecube80

Share this post


Link to post
Share on other sites

Совсем недавно,открыл для себя ещё один гмаксовский секретик в назначении требуемой последовательности такого наложения. Если интересует могу поделиться.Правильно- не правильно,-но работает.

Поделитесь, испробую.

 

А как-то еще подробнее про правку asm-кода можно описать. Я так понимаю bgl получаем через Scasm. Bgl от scasm и bgl от 2004 геймпака различаются друг от друга? или как?

Share this post


Link to post
Share on other sites

Но как бы мы не старались, иногда бывают ошибки и промашки в организации порядка слоев,

в этом случае создаем новый проект и поочередно, слой за слоем, :excl: в нужном порядке импортируем

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

При этом так же не забываем в названии гмакс файлов этих наработок использовать такую фишку,как "1.asphalt" , "2.razmetka" и т.д. в желаемом порядке. И мэржить тоже соответственно. А если,два разных слоя используют одну и ту же текстуру,но должны находиться на разных уровнях,нужно сделать так:

 

 

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

2Bjpg_7591900_6159798.jpg

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

2Cjpg_5354465_6159704.jpg

И делая мэрж,выбираем (ставим галочку) USE Scene material

 

 

И ошибок,во всяком случае у меня,пока не было.

Это только теория

...неоднократно подтверждённая и на практике

а вот Саша (Phemmer) этот принцип использует в данный момент при создании Шереметьево,

Может он заметит наши волнения по этому поводу? :)

Он приветствует её уже давно. :yes: Edited by Marlboro

Share this post


Link to post
Share on other sites

Что мешает в финале объединить все слои в 1 бгл, как описано здесь, во второй части:

http://fsdeveloper.c...ons_(ASM_tweak)

Я этот способ так и "не вкурил",заветную бглку так и не получил... Буду благодарен,если кто объснит "на пальцах".

Share this post


Link to post
Share on other sites

Поделитесь, испробую.

 

А как-то еще подробнее про правку asm-кода можно описать. Я так понимаю bgl получаем через Scasm. Bgl от scasm и bgl от 2004 геймпака различаются друг от друга? или как?

Вам,для начала желательно,окончательно определиться.Компилируете ли вы все слои подложки разными слоями,(с последующим объединением всего в одну бгл),или же перегоняете всё,что "лежит на земле" одной сценой.Я голосую за 2-ой вариант

P.S. Объединение в финале всего в одну бгл никогда никому ничего не давало. Положительно это влияет только на количество бгл в сцене.Не более! А вот про отрицательные влияния о "переваривании" такого комплекта симом много неоднозначных мнений.

Edited by Marlboro

Share this post


Link to post
Share on other sites

Объединение в финале всего в одну бгл никогда никому ничего не давало. Положительно это влияет только на количество бгл в сцене.Не более!

Экспорт всех "слоев" единым файлом тоже дает одну бгл-ку. Вы так и не объяснили, в чем преимущество Вашего метода.

А вот про отрицательные влияния о "переваривании" такого комплекта симом много неоднозначных мнений.

Где можно увидеть эти мнения и оценить их неоднозначность?

P. S. Разглядываю содержимое Кольцово 2012, в ней 8 бгл-ок со слоями.

Share this post


Link to post
Share on other sites

Экспорт всех "слоев" единым файлом тоже дает одну бгл-ку.

Это совершенно разные бглки.

Вы так и не объяснили, в чем преимущество Вашего метода.Где можно увидеть эти мнения и оценить их неоднозначность?

Это не мой метод Я лишь внимательно учусь :)

P. S. Разглядываю содержимое Кольцово 2012, в ней 8 бгл-ок со слоями.

Этот факт никак не опровергает других мнений. С таким же успехом мы можем рассмотреть с десяток дургих примеров. Где как раз всё в одной сцене. Тут уж всё зависит от точки зрения автора сцены. Вернее от её обоснованности. Мне например тоже пришлось фотоподложку перегнать отдельным слоем от слоя искуственного покрытия. Ну не хотели отображаться плоские полигоны в моём случае,если перегонять их одной гмаксовской сценой.И никто так и не смог понять причину.Но в идеале так было бы правильнее.

Edited by Marlboro

Share this post


Link to post
Share on other sites
Это не мой метод Я лишь внимательно учусь :)

Ок, метод не Ваш, я выразился так для краткости.

По ссылке не совсем то. Там идет речь не о наземных полигонах и способах их компиляции, хотя тема, безусловно, интересная.

Я вот сейчас закинул по очереди слои своей недосцены в МСХ, посчитал количество дроколов и полигонов в сумме. Затем закинул туда же "объединенную" бглку и получил те же цифры. Отбросив всякую мистику, можно предположить, что движку игры фиолетово, как обсчитывать треугольники и текстурить их. Что касается многочисленных рефпойнтов, то такая БГЛ-ка как раз и объединяет их в один, если судить по асм-коду. Впрочем, то же самое делается и путем экспорта из Макса единого файла, каким бы способом он ни был получен.

Было бы интересно сравнить различные методы объективно.

Share this post


Link to post
Share on other sites

Докладываю обЪективно :)

Сооружая одну из сцен я поставил в нее более 7000 обЪектов разного уровня сложности, начиная

с замысловатого терминала с нехилой детализацией и заканчивая деревьями.

При раздельной установке в сим этих обЪектов ФПС был в пределах 13-15.

При обЪединении всех этих обЪектов в одну модель ФПС поднялся до 118!

Ни это ли пример?...

 

Но мы то знаем, что в сцене есть много обЪектов с разными свойствами, то огоньки, которые должны

гореть только ночью, то здания, с крыш которых зимой свисают сосульки, то деревья, меняющие

свой наряд каждый сезон и так далее...

Так вот, нужно разложить все обЪекты сцены по категориям условий и так-же использовать для

каждой свою БГЛ.

 

Но мы то обсуждаем именно слоенку подложки и эти слои обрабатываются одни модулем,

соответственно - все слои можно пихать в одну БГЛ посредством ГМАКСА.

Если же линковать готовые БГЛ-ки в одну, то никакой пользы от этого не будет! Ибо каждый

слой имеет свой собственный РЕФПОИНТ и на его обработку сим и тратит уйму ресурсов!

 

Последнее проверял лично, описано выше.

Share this post


Link to post
Share on other sites

Спасибо за "доклад" :) Убедительно, но... Когда речь идет о тысячах объектов -- вопросов нет. Но сколько обычно бывает слоев? Десяток, от силы. Стоит ли заморачиваться из-за мизерного прироста производительности?

Share this post


Link to post
Share on other sites

Спасибо за "доклад" :) Убедительно, но... Когда речь идет о тысячах объектов -- вопросов нет. Но сколько обычно бывает слоев? Десяток, от силы. Стоит ли заморачиваться из-за мизерного прироста производительности?

Мне на Белгороде не хватило 16 слоев, пришлось один промежуточный пихать между 15-м и 16-м :)

 

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

Share this post


Link to post
Share on other sites

Принято, спасибо. Значит есть еще куда оптимизироваться.

Share this post


Link to post
Share on other sites

Вот,как бы..,немного в эту тему и ещё такой волнующий меня в последнее время момент. К примеру,хотелось бы в одну mdl включить больше деревьев,чем того позволяет MDLTweaker. В частности,напомню,что его посредством мы привыкли править нормали. Дело в том,что всё остальное можно сделать и вручную редактированием файлов ***.asm и ***_0.asm Но править вручную нормали,когда полигонов очень и очень много,и врагу не пожелаешь.. Кто как выкручивался? Не подскажете способ?

Share this post


Link to post
Share on other sites

Вот,как бы..,немного в эту тему и ещё такой волнующий меня в последнее время момент. К примеру,хотелось бы в одну mdl включить больше деревьев,чем того позволяет MDLTweaker. В частности,напомню,что его посредством мы привыкли править нормали. Дело в том,что всё остальное можно сделать и вручную редактированием файлов ***.asm и ***_0.asm Но править вручную нормали,когда полигонов очень и очень много,и врагу не пожелаешь.. Кто как выкручивался? Не подскажете способ?

Функция "Найти ... и заменить на ..." - текстовых редакторов с такой функцией предостаточно... На MDLTweaker "свет клином не сошелся"...

Share this post


Link to post
Share on other sites

Функция "Найти ... и заменить на ..." - текстовых редакторов с такой функцией предостаточно... На MDLTweaker "свет клином не сошелся"...

Есть такие возможности. Всякие батники-перебатники. Я б ещё давно заморочился,но все они работают по схеме "найти" что то конкретное,и всё это заменить на что то конкретное. Ну какие конкретности могут быть у 8-и значных цифр нормалей,которые седержатся в текстовом файле изначально после экспорта.Это не подходит. Я всё же надеюсь,что" а может быть" самому makemdl.exe как то задать это изначально. Чтобы,при необходимости "умел" делать это по заказу. Ведь,если не ошибаюсь,это с его помощью создаются файлы asm. Если ошибаюсь,-поправь пожалуйста. "Кто" там при экспорте создаёт эти файлы,и можно ли "ему" задать какие то свои параметры Уже хотелось бы решить этот вопрос,в частности для возможности компилирования большого количества деревьев одной сценой

P.S. Или это можно изначально задать ещё в самом гмакс -е...

Edited by Marlboro

Share this post


Link to post
Share on other sites

1. Все бглки не использующие напрямую текстур (например бглки лэндклассов, которые косвенно используют общие текстуры лэндклассов), необходимо размещать в сценарные папки неимеющие параллельных папок текстур.

 

2. 4-х значный номер в имени бглок лэндклассов (LD_хххх.bgl) обозначает принадлежность к конкретным LOD5.

Совпадение этих номеров в бглках разных сценариев означает принадлежность этих сценариев к одному LOD5.

 

В таких ситуациях, можно не бояться "наложения" (перекрытия одних другими) и достаточно переименовать (добавить к номеру через дефис имя сценария) бглки лэндклассов. При местах "наложении" таких бглок, в симе будут отображаться текстуры лэндклассов более приоритетной бглки. Если не нравиться "наложение", то измените приоритеты.

 

Но, по хорошему, всегда лучше для разных сценариев в конкретном LOD5 объединять их в единой бглке для этого LOD5. Составить их заново несложно , SBuilder в помощь...

Скажите, а как вы вообще относитесь к идее, собрать все ленд-классы всех сценариев в кучу, и подключить их отдельным сценарием без текстур в самом низу библиотеки?

Просто я никак не могу победить безнадёжную утечку памяти в сумеречное время в сценариях Иваново, Пскова и Кирова. Что только не перепробовал, включая и выше упомянутый мною...

Edited by Сокол

Share this post


Link to post
Share on other sites

Скажите, а как вы вообще относитесь к идее, собрать все ленд-классы всех сценариев в кучу, и подключить их отдельным сценарием без текстур в самом низу библиотеки?

Нормально. Только не "в самом низу", над Default Scenery.

Share this post


Link to post
Share on other sites

Есть такие возможности. Всякие батники-перебатники. Я б ещё давно заморочился,но все они работают по схеме "найти" что то конкретное,и всё это заменить на что то конкретное. Ну какие конкретности могут быть у 8-и значных цифр нормалей,которые седержатся в текстовом файле изначально после экспорта.

А если вот так:

 

post-12933-0-33549100-1351320158_thumb.jpg

 

то Notepad++ это сделает мгновенно и без ошибок

Share this post


Link to post
Share on other sites

Marlboro, какие именно значения нужно менять в *_0.asm? Если те, что на скрине у ANRI, то могу добавить эту функцию в парсер. Чем больше таких "твиков" наберется, тем меньше придется пользоваться редакторами, а файлы будут правиться парой кликов.

Единственное "но": у ANRI пример, похоже, из 2004 ГП, а программа заточена под асм-ы 2002. Вряд ли они идентичны.

Edited by Nizkovoltnik

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...