воскресенье, 17 января 2016 г.

Побочный продукт.

   В процессе подготовки алгоритма движения по ландшафту с помощью карты высот создал небольшой пример во-первых, определения векторов направления координатных осей объекта, обзовем его опорным, а во-вторых, пересчета координат другого объекта (цели) из локальной системы координат опорного объекта в мировые. Пару раз перечитал предыдущее предложение, вроде сам понял, что написал ))).  Качайте, если интересно. Управление - стрелочки. Размер небольшой.
rotAxis.blend.7z
    Мне такая штука нужна для определения координат опорных, в прямом смысле этого слова точек. С помощью этих координат я буду выковыривать значения высоты из карты высот, а по значениям высоты буду строить матрицу ориентации для юнита, если сумею, конечно. По идее я как раз должен был сейчас делать алгоритм построения матрицы и проверять, корёжит ли юнит при движении по холмистой местности и не погружает ли он свои "колеса" слишком глубоко. А вот отвлёкся. И с картой высот и блочным ландшафтом тоже интересная вещь получается - в процессе "прикидок" выбирал размер блока как компромисс, что бы и блок был не слишком мелким, и расстояние между высотами не слишком большим, поскольку полагал, что блоки возьмут на себя функцию карты высот. А теперь получается, что карта будет отдельно от блоков. И можно опять (!) переделывать блочный ландшафт под удобный размер. Всегда советовал для начала выбирать удобный формат данных, а потом уже реализовывать, а сам получается своим советам не последовал.

суббота, 16 января 2016 г.

Пробую сделать движение по рельефу.

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






среда, 13 января 2016 г.

Повторение пройденного.

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

вторник, 5 января 2016 г.

Получение списка файлов в папке с помощью os.listdir()

Внезапно обнаружил, что не написал про такую удобную функцию питона. А ведь собирался! Склероз проклятый...

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


import os

def main():
    # получаем список имен всех файлов в папке, где лежит наш скрипт, если хотите другой           # путь, то его нужно указывать вместо точки в кавычках в аргументе функции listdir.
    L = os.listdir('.')
    # "фильтруем", любуемся в консоли на список бленд-файлов в текущей паке.
    for obj in L:
        if '.blend' in obj:
            print(obj)
    return 0

if __name__ == '__main__':
    main()

  

среда, 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() реализованно аналогичным образом.