среда, 30 декабря 2015 г.

Не мытьем, так катаньем...

Не сумел сообразить, как передать аргументы на запуск в блендерплейер, зато сообразил, что можно просто создать файл сценария операционной системы и уже его запустить. Однако получилось.  Еще не сообразил, как отправлять совместно некоторые аргументы, но задание разрешения уже работает. Понятно, что у вас пути и имена файлов должны быть иными.
P.S. Сообразил, достаточно указать явно оболочку оси типа:
x = subprocess.Popen([gameName + '  ' + arguments], shell = True) и все заработает. Ну, почти все.
 Ниже уже не нужный скриптец:


вторник, 29 декабря 2015 г.

Типа лаунчер.

Почему-то не удается менять разрешение, да и остальные параметры почему-то не работают. Надо думать. Но можно выбирать в окне или в полноэкранном режиме будет запущено.

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

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import subprocess

pathToPlayer = '/home/denis8424/blender-2.75-linux-glibc211-i686/blenderplayer'
arguments = '-f 1920 1080 32 60 -g show_profile = 0'
gameName = '/home/denis8424/bge/mipmap.blend'
x = subprocess.Popen([pathToPlayer, arguments, gameName])

Про параметры из самого блендерплейера:

воскресенье, 27 декабря 2015 г.

Всех с наступающим! И немного про агрегатирование.

    Агрегатирование - удобная вещь. Заключается оно в том, что экземпляр класса А со всеми своими данными и методами, используется как свойство класса Б. Собственно, ничего удивительного - каждый раз, когда мы прописываем в определении какого-то класса свойство, например типа int, то происходит именно агрегатирование, поскольку тип int - это и есть определение объекта класса, а свойство этого типа - экземпляр его. Для чего удобно агрегатирование? Во-первых, пользовательские типы данных - это удобно, где бы мы их не использовали. Во-вторых, мы таким образом получаем дополнительное подпространство, если можно так выразится, имен. В-третьих, часть методов класса вполне можно перенести в определение агрегатируемого класса, а там уже и дополиморфизма и прочих ништяков недалеко...
    Вот, приспичило мне на днях сделать нормальную реализацию состояний клавиатуры для pygame. Что бы можно было в игровом цикле проверить, нажата ли клавиша "М" и как давно. Почему я занялся этой библиотекой - другой вопрос, но дело в том, что либо я не нашел в описании API соответствующей функции, хотя вроде искал, либо её там отродясь не было. Точнее оно там есть, но зело неудобно пользоваться- доступ только по числовому индексу клавиши, и из всех состояний - только нажата клавиша, или отпущена, причем при зажатой клавише событие не генерируется. То есть если вам нужно смещение персонажа при нажатой стрелочке "вправо", то на эту кнопку придется нажимать со скоростью пулемета "Максим"Зажатой и удерживаемой стрелочки для него не существует. Не суть важно, главное, что в любой момент можно запросить состояние всех клавишь, и получить кортеж с кучей 0 и парой единиц, индексы которых соответствуют числовому коду клавишь. А имя клавиши можно узнать также с помощью функции библиотеки pygame, просто скормив ей индекс.


class keyboard(object):
    def __init__(self):
        keys = pygame.key.get_pressed() # получаем кортеж текущих состояний клавишь
        self.buttons = buttonList(keys)  # создаем список кнопок клавиатуры
        self.status = keyStatus() # дописываем в объект переменные

class buttonList(object):
    """ объект хранит в своих переменных объекты - кнопки клавиатуры"""
    def __init__(self, keys):
        for index in range(len(keys)):
            currName = pygame.key.name(index)
            self.__dict__[currName] = button(index, currName, keys[index])

class button(object):
    """объект реализует клавиши клавиатуры"""
    def__init__(self, index, name, state):
        self.index = index
        self.name = name
        self.currentState = state

class keyStatus(object):
    """ объект просто хранит переменные в удобном для использования виде"""
    def __init__(self):
       self.FREE = 0
       self.DOWN = 1
       self.HOLD = 3
       self.UP = 4


За работоспособность кода ручаться не буду, писал прямо с мозга, но суть понятна - объект одного типа записывается в свойство объекта другого типа, а уже тот в свойство третьего. Там еще кучи функций не хватает для полноценной работы, типа обновления состояния клавишь и прочего. Полная версия умеет вроде как так:
X = 1000
key = keyboard()
key.update()
if key.buttons.escape.status == key.status.DOWN:
    # QUIT на самом деле здесь конкретный код выхода из игрового цикла
if key.buttons.right.status == key.status.HOLD:
    X = X - 1
Определение статуса кнопки я здесь не прописал, как и таковое свойство, но оно в оригинале есть, как и еще куча методов.
На что похоже? Правильно, pygame.key.name() реализованно аналогичным образом.

суббота, 28 ноября 2015 г.

Добил миникарту.

Вроде выжал все что мог. Сам пример базируется на коде из tutorialforblender3d и известном примере рисования в реалтайме на текстуре. При запуске создается одномерный массив(map) координат(points), кстати массив с основанием больше 1024 здорово грузит систему при инициализации, затем в координаты рандомно расставляются кубики-персонажи. Координата, в которой находится кубик, считается занятой, и на миникарте должна отображаться цветом, отличным от фона. Для миникарты инициализируется новая текстура, и две кисти разного цвета. При движении кубы выбирают соседние незанятые координаты, перемещаются в них и записывают в специальный список список индексы новой занятой координаты и старой, уже получается не занятой. Также самим координатам сообщается, заняты они или свободны. Этот список пробегает цикл отрисовки, и в зависимости от свободности координаты рисует плоттером в нужном месте текстуры кистью, или создавая метку на мониторе, или замазывая её цветом фона. Все просто.





вторник, 20 октября 2015 г.

Удалось сделать новый материал. "Кубизм" вылез в новом месте.

   Как обычно, ноды. Единственная неприятность - используется Vertex Color, для разделения материалов с одной высотой, а это означает, что если сетка не слишком частая, то вылезет "кубизм", а если почаще ставить, то возрастет нагрузка на движок. Может всё сделать в стиле пиксель-арт? )))
    Теперь еще надо разобраться до конца со спайсом, он ведь должен добавляться и исчезать и применить материал на блоках ландшафта.

    Ниже картинки, материал и результат:


понедельник, 12 октября 2015 г.

Геометрия капут. Вроде )))

    Вожусь потихоньку с материалами. Теперь на блоках аж три нодовых материала, один с разделением по высоте трех материалов, второй - двух, а еще один два материала смешивает по высоте и еще один всовывает в пятно от Vertex Color. Киш-миш и люля-кебаб. Ниже картинки:

пятница, 9 октября 2015 г.

Blog by Flogger-K. 3D и не только: МиГ-29. Кабина и ее правые пульты.

Blog by Flogger-K. 3D и не только: МиГ-29. Кабина и ее правые пульты.: Застaвил себя взяться за приборную доску "девятки".  Все дело в том, что ее облик довольно своеобразен. И вызвано это своеобразие ...

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

    Все игровые объекты в BGE являются экземплярами классов, предоставляя пользователю широкий выбор возможностей для управления. Есть конечно нюансы, например новый экземпляр класса, наследующего базовый, невозможно создать "с нуля", обязательно нужно "мутировать" старый экземпляр, в офф. документации есть пример кода, его обязательно нужно прочитать. И есть один затык - " а как же собственно, созданным экземпляром управлять?" То есть как вызывать дописанные нами функции? Попробуем разобраться.
   

суббота, 3 октября 2015 г.

Геометрия наносит ответный удар.

    Внезапно выяснил, что сделал перепад высот между уровнями a и d слишком большим, даже пологий спуск получается порядка пятидесяти градусов, что несколько занадто. Пришлось делать максимальную высоту в полтора метра вместо трех. Как результат - все предыдущие блоки отправились в пустыню в утиль. Начал делать всё снова, а раз уж пошла такая пьянка, несколько изменил геометрию, используя как образец для подражания вид кочки горы из сеговской Dune II:
 
    Однако без косяков не обошлось, плавные спуски надо переделывать, наверное уже в пятый или шестой раз. Геометрия, блин. Зато насобачился клепать их быстро, если бы еще без ошибок... Параллельно поправил материалы, сделал более жесткую границу между материалами, убрал реакцию на освещение, слегка выкрутив параметр Emit, убрал перебамп путем полного отключения и сделал размытие текстурной маске. Результат ниже:

воскресенье, 27 сентября 2015 г.

С переменным успехом идет война с геометрией.

    Третий вариант поворота вроде как удался. Второй вариант, состоящий из 8 мелких блоков отправится на свалку истории, потому что я не смог сделать к нему плотно примыкающий изгиб. Пришлось сделать новый, заодно сообразил, что восемь блоков всегда идущих вместе, вполне можно заменить одним, а остальные блоки ландшафта в том месте заменить пустышками. Теперь еще спуск переделать надо будет, но там не сложно, простое экструдирование, и более сложное - границу спуска, там уже выдавливанием не обойдешься. Короче, всё остальное про спуски переделывать. И алгоритм редактора тоже, причем серьезно. Поработал с материалами, точнее с текстурами к ним, вроде ничего получается, только никак не вспомню - более темный цвет кажется ближе, чем более светлый или наоборот? Надо подкрутить яркость текстур, но в какую сторону?
Ниже картинки, как бы сетка и в материалах:


вторник, 22 сентября 2015 г.

Попалось интересное видео.

    На blendernation.com наткнулся на интересное видео от John Hamilton. Суть в том, что используя анимацию цвета можно в режиме реального времени, в игре то есть, изменять некоторые цифровые значения в нодовых материалах, например величину смешивания цвета или изменять расстояние исчезновения материала. Сам автор склепал пример изменения координат UV - развертки, который прекрасно подойдет для анимации чего-то вроде бегущей воды или гусениц танков, без скрипта и программирования. Прямо идеал BGE. А если учесть, что с версии 2.76 параметры материалов будут доступны для изменения через скрипт, то получается, что можно встроить в ноды целую кучу "крутилок".
Вот, склепал картинку, правда пока не получается подобрать размер текстурки, чтобы зациклить:




    Там же попалось видео использования привязки к " абсолютной сетке", очень удобная, наверное вещь, давно бы её сделали.

понедельник, 21 сентября 2015 г.

Во-о-от новый поворо-о-от...

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


воскресенье, 20 сентября 2015 г.

Опять кубизм вылезает...

    Рукалицо. Есть конечно еще один вариант, но он не позволит создавать столь малый радиус поворота, а имена станут намного сложнее. Или фиг с ним? Обзову игру DuneCraft' ом или MineSpice ))) . Есть еще косяк с текстурой, но там просто текстуры надо менять на нормальные бесшовные. Ниже картинка.


четверг, 17 сентября 2015 г.

Сглаживание ландшафта.

       Сообразил как сделать более гладкий и естественный ландшафт.  [сарказм]В который раз.[/сарказм] В связи с этим потихоньку делаю новый файл ресурсов, потом надо будет пилить редактор, потому что алгоритм изменится. Я еще хочу что бы блоки ландшафта одного типа были нескольких видов, для разнообразия картинки. В общем переделок много, а времени на них нет, в день по полчаса, по часу трачу. Учитывая, что я предпочитаю решать задачи методом штурма, приходится трудно. Спасает небольшой полученный навык ретопологии, высоты точек быстро сводятся. И что я сразу за Dune 2000 и  Emperor взялся? Надо было Dune II копировать, там из рельефа местности полторы кочки... Ниже картинка текущего прогресса за несколько дней работы по вечерам. Видно, что блок 1bcba надо переделывать, да и вообще весь этот ряд.


вторник, 25 августа 2015 г.

Техническое.

У меня сейчас полный швах со временем. Работа по двенадцать часов, шесть-семь дней в неделю, график нестабильный, конечно, иногда бывают выходные, но я их трачу на решение неотложных дел. Посему пишу сейчас в блог редко и так будет до конца уборочной кампании, и осенней посевной скорее всего, ну еще надо линии обслужить-отремонтировать. 

понедельник, 10 августа 2015 г.

Как рассчитывается баллистическая поправка.

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

воскресенье, 9 августа 2015 г.

Добавил пример самонаводящейся турели с баллистическими поправками.

Кому лень искать, вот ссылка:
turret3.blend.7z (~70 kB)




Blog by Flogger-K. 3D и не только: Третье видео.

Blog by Flogger-K. 3D и не только: Третье видео.: Сделал третье видео. что там происходит - я дал котокое описание. Добавлю, что кампания была сделана так, чтобы можно было при выходе из иг...

Сделал еще вдогонку пример паузы.

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




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

Выложил пример монитора радара.

Появилось немного свободного времени, поэтому оформил пример монитор радара и выложил у себя в примерах. Если лень искать, то вот ссылка:
radarIs.blend.7z (~75 kB)
Особых дополнений по сравнению с предыдущей версией нет, просто обе функции собраны в один модуль, добавлены комментарии и расчет положения метки относительно монитора радара идет в только по осям X и Y.




суббота, 18 июля 2015 г.

Сваял "на коленке" пример радара.

Пока не оформлен, но ИМХО все понятно и так: объект, обладающий радаром пишет в словарь данные дистанции и направления на цель, в оверлейной сцене, объект реализующий монитор радара масштабирует дистанцию, и потом добавляет метки со скрытого слоя, в рассчитанную позицию. Монитор можно перемещать.

radarIs.blend7z

четверг, 16 июля 2015 г.

Бреющий полет


Разместил камеру пониже, намалевал ландшафт и записал видео:


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

пятница, 10 июля 2015 г.

Не утерпел и сделал новый файл ресурсов.

Конкретно блоков ландшафта. Получился вырвиглазный кубизм,  но по сравнению с предыдущим вариантом, пожалуй лучше будет. Eще малость побаловался с нодовым материалом, для разделения по высоте. Текстуры еще надо будет по цвету подобрать. Как оно выглядит:


суббота, 4 июля 2015 г.

Жара...

Вот только в отличии от Flogger-K, никаких систем охлаждения в моей халупе не предусмотрено. Я еще прокатился по жаре на моем корче, не оборудованном кондиционером, километров пятьдесят - душегубка, однако. Хотя, если вспомнить, как я на "жигуле" в менее жаркую погоду ездил, то еще ничего. Перегрелся малость. К чему это я?, а вспомнил - при такой температуре и сколько-нибудь длительном мыслительном процессе мозги перегреваются и срабатывает защита, в виде лени. Посему охлаждаюсь пивом, у которого есть еще один приятный в моем случае побочный эффект - креатив прёт как на дрожжах. Конечно, я не рискую лезть с серьезными переделками в свои проекты, поелику точный расчет зависимости необходимого количества потребленного пива в отношении температуры окружающего воздуха не поддается формализации, в силу неизвестности скорости протекания метаболических процессов... что-то меня понесло, перепил. ))) В общем склепал пример, полезный при создании файтингов. Камера следит за двумя персами, и приближается/удаляется, что бы они влезли в экран.  Позже выложу в свои примеры. А пока вот:

camTo2pers.blend.7z (~61 kB)

P.S. Добавил.

P.P.S. Весь код после 50 строки можно заменить на
camera.applyMovement([0.0, 0.0, pers1scrX * -2 +0.2], True)


пятница, 3 июля 2015 г.

Сообразил, как сделать более плавный ландшафт.

   Пикассо конечно, однако пока это лучший вариант, в отличии от текущего. И с высотой блока не придется мучатся брать среднюю высоту, да и все. Хотя с переделкой спешить пока не буду, вдруг еще чего в голову придет... Ниже картинка, для пояснения:



четверг, 2 июля 2015 г.

Отвлекся.

Пришло в голову проверить простейший алгоритм обхода препятствий. Сделал. Результат - как сказал Винни-Пух Пятачку: "Не то что бы совсем не попал..." Иной раз удивительным образом обходит все препятствия, прямо гордость берет, а иной раз упрется как баран в новые ворота.  Но похоже на движения юнитов в DuneII, аж ностальгия пробивает, кто играл, тот поймет. Коротенькое видео:




вторник, 30 июня 2015 г.

Опять переписал генератор регионов.

   Уже наверное, пора ярлык вводить - "переписал генератор регионов". Однако, буду еще переписывать, похоже, есть такое ощущение... Еще добавил для регионов генерацию словаря связанных регионов, со списком индексов общих блоков для каждого. Оно будет надо сильно впоследствии, для вывода юнита в соседний регион.
  Так и не сообразил, как указать высоту блока, тем более, что блок может иметь сразу несколько высот. Типа "b,c,b,a" - весь диапазон высот присутствует. Это для "а,а,а,а" или "с,с,с,с" - никаких проблем.  Надо думать...
Ниже код, хотя без кода классов, оно малопонятно. Длиннота:

пятница, 26 июня 2015 г.

Немного переписал генератор регионов.

А то совсем странно выглядело. Сейчас оно сделано так:

def genRegions(self):
        tempRegionList = []
        for currentBrick in self.brickList:
            if currentBrick.regions == []:
                relList = []
                tempList = list(currentBrick.relatedList)
                for i in tempList:
                    brick = self.brickList[i]
                    #print(brick.h - currentBrick.h)
                    if (brick.regions != [] or 
                    brick.h - currentBrick.h > self.maxH or 
                    self.getDistTo2(currentBrick.position, brick.position) > self.regionDist):
                        brick.regions.append(currentBrick.index)
                        relList.append(brick.index)
                    else:
                        brick.regions.append(currentBrick.index)
                        relList.append(brick.index)
                        #print(brick.relatedList)
                        for appB in brick.relatedList:
                            if appB not in tempList:
                                tempList.append(appB)
                            
                        
                #print(currentBrick.index, relList)
                newRegion = landRegion.landRegion(currentBrick.index, relList)
                tempRegionList.append(newRegion)
                        
        print(tempRegionList)                 
        return 0

Еще надо дописать определение соседних регионов и списка общих точек. И как сделать определение высоты точки, вот в чем вопрос, ведь один блок ландшафта может содержать в себе все уровни высоты...

воскресенье, 7 июня 2015 г.

Начал набрасывать генератор регионов.

   Зато пока сообразил, как сделать, чуть мозг не поломал, но вроде сдвинулось с мертвой точки, тьфу-тьфу-тьфу... Здорово помог MyPaint - редактор графический. Рисовал вручную точки, соединял их линиями, пытался прикинуть, как оно должно работать. Немножко отвлекся, нарисовал картинку, смотрите ниже. Код пока еще страшный, состоит только из генератора списка блоков. Наверное вынесу его в отдельную функцию - пригодится для расчета полей зрения и вообще... Сам класс региона я написал аж в двух вариантах, и оба пойдут в утиль. Еще надо написать определение связанных регионов. Код ниже:


среда, 27 мая 2015 г.

Набросал парсер

Сие поделие создает файл в текущей директории и пишет в него данные блоков ландшафта в текстовом виде. Оно относится к классу ландшафта, поэтому нет проблем со сбором информации. Текст:

def parser(self, filename):
        f = open(sys.path[0] + '/' + filename, 'w')
        # просматриваем все блоки ландшафта
        for brick in self.brickList:
            # создаем строку - список связанных блоков
            relL = '|'
            # проходим список связанных блоков
            for rel in brick.relatedList:
                # добавляем в строку индекс связанного блока
                relL = relL + str(rel) + '|'
            # собираем данные в кучу, для записи
            line = (str(brick.index) + '-' + str(brick.position[0]) + '|' +
            str(brick.position[1]) + '|' + str(brick.position[2]) + '-' +
            brick.nameMesh + '-' + relL + '-\n')
            # записываем
            f.write(line)
        f.close()

Кусочек результата:

0-0.0|0.0|0.0-a,a,a,a-|1|16|17|-
1-2.0|0.0|0.0-a,a,a,a-|0|2|17|16|18|-
2-4.0|0.0|0.0-a,a,a,a-|1|3|18|17|19|-
3-6.0|0.0|0.0-a,a,a,a-|2|4|19|18|20|-
4-8.0|0.0|0.0-a,a,a,a-|3|5|20|19|21|-
5-10.0|0.0|0.0-a,a,a,a-|4|6|21|20|22|-
6-12.0|0.0|0.0-a,a,a,a-|5|7|22|21|23|-
7-14.0|0.0|0.0-a,a,a,a-|6|8|23|22|24|-
8-16.0|0.0|0.0-a,a,a,a-|7|9|24|23|25|-
9-18.0|0.0|0.0-a,a,a,a-|8|10|25|24|26|-


пятница, 24 апреля 2015 г.

Перенес ландшафт в основную сцену.

Еще переключил камеру в перспективный вид и слегка наклонил - получилось лучше. И так, по мелочи поковырялся. Больше ничего не делал.


понедельник, 20 апреля 2015 г.

Пример риалтаим скульпта в BGE.

Склепал по просьбам трудящихся. Ваял на коленке, посему вельми неказисто. Ноги растут из примера UV- скроллинга. Если будете использовать, или, тем паче, улучшите, буду благодарен если сообщите.

Управление - тыкать курсором в плейн и нажимать на левую клавишу. Колесико мыши увеличивает/уменьшает дистанцию, на которой вертексы реагируют. Смотреть проперти dist. Клавиши W, S регулируют силу воздействия - свойство add. Разберетесь, там не сложно.




P.S. Если хотите реально скульпт, то надо изменять координаты не просто по глобальной оси Z, а по нормали. 
P.P.S. Добавлю себе в примеры.

вторник, 14 апреля 2015 г.

Скучно...

Делать нечего, комп далеко, со скуки накатал  с планшета на чистом Питоне прототип эмитера частиц. Эдакий сферический эмитер в вакууме... Понятно, что все сырое и к практическому применению не готовое. Однако для ознакомительных целей сгодится.


понедельник, 13 апреля 2015 г.

Есть прогресс с отображением через BGL. #1

   Кто же знал, что процесс шлифования миникарты вдруг принесет неожиданные плоды - шальная мысль, вдруг пришедшая в голову, оказалась правильной и мне удалось отобразить glQUADS в перспективном виде. В перспективном - значит, он закрывает и его закрывают объекты сцены в зависимости от глубины и позиции. Полюбуйтесь вот:



Квад (красный) копирует положение усеченного плейна (бледнотик). Поскольку камера наклонена, а квад рисуется в её локальных координатах, то плоскости квада и плейна не параллельны. В итоге наблюдается взаимное пересечение. Я еще сделал рисование квада в произвольных координатах, тоже получается.
Примера и кода пока не будет, потому что сам блуждаю в потемках - что зачем нужно. Хотя разобрался, в системе координат и в порядке вершин (против часовой стрелки). Надо еще понять, как туда всунуть текстуру.

воскресенье, 12 апреля 2015 г.

Есть прогресс с отображением через BGL.

Разобрался с проблемой создания класса, который будет отрисовывать список точек через BGL. Проблема была в том, что раньше я создавал класс каждый раз, когда вызывалось изменение в рисуемой картинке. Теперь вроде бы получается отправлять данные в созданный класс, не громоздя класс над классом. Получившийся вариант скорее подходит для отображения быстро меняющейся обстановки, вроде монитора радара, чем для отображения статичных массивов данных, вроде миникарты. Для миникарты нужно создавать именно что массив обновляемых данных. Бленда не будет, потому что все что нужно- взять объект в сцене, и на сенсор Always повесить контроллер питона с указанием функции init, и на еще один какой-то сенсор, работающий в импульсном режиме, повесить контроллер питона с функцией main. Тем более, что все равно очень сыро. Подсветки синтаксиса тоже не будет.


понедельник, 6 апреля 2015 г.

Выкину пример нодового материала.

Сообразил, что лучше один раз показать, чем сто раз рассказывать. Поэтому выкладываю пример нодового материала с разделением материалов по высоте, и использования в качестве текстурной маски цвета вершин.

landMat.blend.7z ~240 kB

воскресенье, 5 апреля 2015 г.

Исправил ошибку с закольцованостью карты.

Исправил ошибку с закольцованостью карты. Если кому интересно, то в модуле land.py, нужно заменить функцию setNameMesh() на эту, отличия минимальны:

пятница, 3 апреля 2015 г.

Нодовый материал.

Картинка объясняет, как сделать материал, который будет становится полностью прозрачным при приближении. Если надо, чтобы он наоборот становился прозрачным при отдалении - удалите ноду Invert. Нода Material нужна, что бы управлять цветом объекта через object.color. Не забудте поставить галочку напротив ObjectColor в настройках материала. Если это не требуется, удалите эту ноду и соедините узел ноды Texture Color с одноименным узлом ноды Output.


понедельник, 30 марта 2015 г.

Похоже приплыли...

Со времени последнего сообщения не было сделано НИЧЕГО. Некогда. Пишу эти строки, а за окном дождь идет, поэтому появилось чуток времени. Так что выбрасываю промежуточный вариант, кому интересно, посмотрите. Когда продолжу, не знаю.


вторник, 17 марта 2015 г.

Небольшой прогресс.

Немножко повозился с миникартой. Увязал вывод цвета пикселей в зависимости от имени блока ландшафта. Получилось работоспособно, но вылезли пара пара проблем. Одна - просто ошибка выхода за предел индекса списка, которую надо исправить, вторая - проблема размера миникарты, если ландшафт большой, то миникарту раздувает на пол-экрана, а то и больше.  В общем, будем посмотреть.
Ниже картинка:


воскресенье, 15 марта 2015 г.

Разгребаюсь потихоньку с BGL.

    "О, Омнисия, даруй понимание своему аколиту" - примерно так я камлаю в последнее время над этим модулем. Сваял вот примерчик монитора радара, как в RedEclipse -  но он не доработан. Просто пример вывода точек из списка в указанную позицию экрана. Не документирован, в коде с BGL я сам нифига не понимаю, но хвала Омнисии, все работает.

четверг, 12 марта 2015 г.

Хвастать вредно. Юбилей.

    Сперва о плохом. Не писал потому, что во-первых, был несколько занят, и занятость эта в ближайшее время будет увеличиваться до зимы, во-вторых, создание миникарты с помощью модуля видеотекстуры потерпело крах. Почему-то плоттер видеобуфера вешается, при слишком частых обращениях. И фиг бы с ним, но и Блендер тоже подвешивается намертво, приходится вырубать консоль, с которой он запущен. Пришлось подключать bgl,  в котором я ни в зуб ногой. Спасибо пользователю dron, который когда-то давно, еще в далекой-далекой галактике  на БУ, сделал пример использования этого самого бгл. Потихоньку ковыряюсь.

    Теперь о хорошем. Пример dron работает вне зависимости от того, понимаю я, что там происходит, или нет. Поэтому пишу класс миникарты, тупо копипастя код, осталось только изучить Веды. Поэтому есть подвижки, но хвастать пока нечем.
    Дальше - у моего WIP на момент написания сообщения 999 просмотров. Ура-ура, юбилей прямо вот-вот. 

суббота, 7 марта 2015 г.

Добавил промежуточный уровень.

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

пятница, 6 марта 2015 г.

Все получилось.

 Алгоритм оказался ОЧЕНЬ удачным.


Прогресс есть.

Но пока небольшой. Имена мешей генерируются, хотя вылезла проблема с тем, что для определения некоторый типов мешей алгоритм может быть проще, чем для других. Сижу, думаю, может можно как-то упростить? Есть еще вариант, надо думать.
Мне еще добавлять промежуточный уровень, для плавных спусков.
А так, все работает, как надо.


понедельник, 2 марта 2015 г.

Похвастаюсь.

    Работа над редактором блочного ландшафта медленно, но неуклонно движется в перед. "Наше дело правое и мы победим". Благодаря Flogger-K, который натолкнул на мысль, удалось разобраться с определением типа блока по соседним, без всяких "если блок выше такой-то, и блок правее такой-то, а блок левее совсем не такой, то..." Алгоритм более тормозной, но многообещающий. Если получится все правильно оформить, то распишу подробнее.

вторник, 24 февраля 2015 г.

Пока хвастать нечем #2

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

понедельник, 23 февраля 2015 г.

Пока хвастать нечем.

Для редактора блочного ландшафта сделал визуализацию, хотя пока и "не фонтан".  Надо еще поправлять. Уже тестил на карте 1024Х блоков, тормоза есть, но небольшие. Еще нужно запилить изменение соседних блоков от изменяемого и повыкидывать лишнее.

пятница, 30 января 2015 г.

Делаю редактор блочного ландшафта.

Пока упрощенный - надо еще понять, как правильно все сделать. Есть успехи:
1) Уже генерируется базовый ландшафт, состоящий из блоков с высотой 0. То есть "чистое поле". Размер произвольный, тестировал от 8Х8 до 256Х256 блоков.
2) Вроде окончательно решен вопрос с определением индекса блока ландшафта, на который указывает курсор мыши. Да и вообще любой объект, имеющий координаты.
3) Выборочно заменяются блоки ландшафта на другие.


воскресенье, 18 января 2015 г.

Похоже, что домучал класс навигационного узла окончательно.

Когда список атрибутов стал угрожать перевалить за второй десяток, понял, что оно будет жрать непомерно памяти, особенно при копировании списка узлов. Выкинул половину атрибутов, оставив только нужные для расчета пути. Оставил десяток - авось хватит )))). Написал ему функцию рассчета расстояния, сейчас думаю, может лучше выкинуть на мороз в отдельный класс отправить? Этакий mathutils. Дописал также парсер прямо в __init__() ,пускай сам читает данные, не маленький уже. Пока пишу документацию к классу.

среда, 14 января 2015 г.

Вдогонку.

Пришло в голову, как узнавать координату занимаемой ячейки, не сравнивая со всеми возможными координатами.


вторник, 13 января 2015 г.

Сделал пример стены для стратегий.

Краткая суть примера:
Имеем список всех возможных ячеек, в одну из них и устанавливается невидимый объект блока стены, который обнаруживает занятые соседние ячейки и на основании этой информации добавляет себе в потомки подходящий по форме объект стены, уже видимый. Также он изменяет проперти соседних блоков, побуждая их изменить форму своих объектов на другую.
 Дальше - картинка и ссылка для скачивания.

четверг, 8 января 2015 г.

Баловался.


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