Quest3D - Русскоязычное сообщество

Да,поспешил я на счет доступности...Вроде бы было все понятно interface,class,но длшел до factory и все.Не могу понять.Кто нибудь может объяснить что происходит в файле ObjectFactory,узелObjectFactory-GetObject.

А вообще ктонибудь разобрался с Factory? Или все ждут новых примерчиков с оффорума :)

И вообще по ОО хотелось бы чонить подробно и доступно, вот тока перелез на 4 версию.... сразу вопрос встал - чо эт такое?

Это заменитель array,это возможность легко использовать заготовки в разных проектах,это готовые блоки patterns, выполняющие определенные функции и так же возможность использовать в разных проектах.Но,к сожалению довольно сложные и не законченные уроки.Взять ,к примеру,Asteroids в Examples.Так удобно и красиво там все распределено,но разобраться без пояснений тяжко.

a mojet kto znait i umeit polzivaca zakinit na forum videoo :-\ nito nikak ne poluchaitsa a vesh xoroshaa  :)

Я надеюсь уже многие начали ковыряться с ОО:) Поэтому вопрос тем,кто добился в этом больших успехов чем я.Как соединить Factory и Manager?Я слепил в фэктори несколько классов,но менеджера надо применять к одному классу т.е.надо каким то образом профильтровать instance ref conteiner по class instance.Пробовал интерфейс команды не получается.Пытался разобраться с этим в астероиде,но там очень уж все закрученно- по другому сделан factory,добавлен Asteroid Enginee.Может есть более простое решение или все-таки астероид?

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

скачал недавно с оффорума примерчик с Resource Manager(в смысле не канал,а из раздела ОО).Вчера начал с ним разбираться.Получается ,что для каждой текстуры (диф,норм,лайт) надо лепить своего менеджера.А еще,можно по такой схеме организовать HLSL.Так ли это?И действительно ли это настолько эффективно?Честно говоря думал,что достаточно просто удалять(добавлять)ссылки из InstanceRefContainera, в смысле объекты полностью.

Попробовал я вчера понашлепать обьектов с загрузкой текстуры с Resource Managerom и обычным способом.FPS одинаково падает с увеличением кол-ва объектов.Т.е.это видимо актуально при одновременной выгрузке ,а точнее загрузке множества объектов.

Кто нибудь разобрался с OO Collada import ом.Как из загруженной сцены отдельный объект выдернуть,например,чтобы шейдер прилепить?Текстуры и object data выдлены в отдельные классы и как их в один обьект объединить...

Привет всем. Кто нибудь знает где можно взять примеры с OO Interfase, или статьи, уроки, что нибудь.

Вчера,ковыряясь в разделе ОО оф.форума я прочитал(если,конечно правильно понял-промт+школьноинститутский англ на4с минусом:)),что ClassInstList ,не предназначен для хранения и постоянно перезагружается,а данные хранятся в XML файле.
Это был вопрос ,а внятного ответа от квестовцев я не нашел(не понял?)Т.е.это относится к любым,в том числе и статическим объектам?

Опять на оффоруме наковырял ,в материалах конференции,пример GUI OO и краткое описание.К сожалению пример сделан в RC5,так что пока остается описание.Общий принцеп понятен-так же,все через factory,описание иньерфейсов есть,но самое главное-взаимоотношение child-parent не могу понять.Может кто разобрался и объяснит?

Блин! Неужели никто не разбирается с ОО ?
Очень хочу разобраться, юзаю хелп, но не все ясно.
Проблема такая:

Есть несколько EditBox, которые создаются через ОО. И вот я ввожу в них данные, как мне их извлечь? Никаких счетчиков, как скажем просто в Array нету. И вот как динамически извлекать данные?

Если определенный объект ,то Ref From Container по индексу,если по какому либо параметру,то for each и if.
ковыряй asteroids:)

Пасиба, anval! Все работает вроде бы! В любом случае совет ценный, пригодиться! :)

ой помогите еще, люди добрые! В общем есть большое количество шаров с физикой, которые катаются по полю. Сделаны они с использованием ОО. И вот надо мне вычислить дистанцию каждого из них до определенного объекта. Их положение определяется ODE Body. Я пробовал просто вытащить положение из матрицы ODE и соответственно получить дистанцию до друго вектора, но так у меня производятся вычисления лишь для последнего шара, а не для всего набора, хотя все это делаю внутри функции, которая итериться n раз. Как быть?

Помогите кто чем может! У меня еще проблема с ОО. К предыдущей добавилась еще одна. Но обе из одного раздела фактически. Объясните, чем отличается цикл FoorLoop у Array и For each class instance list у ОО?

Мне нужно внутри цикла создать n-штук EditBox и заносить в массив их содержимое после каждого изменения этого самого содержимого. То есть при срабатывании OnChangeEvent. Но у меня все происходит со сдвигом на один шаг. То есть я ввожу последовательно числа [1,2,3] а в массив заносятся [ничего,1,2]
С чем это может быть звязано? Я думаю, что неверную структуру сделал, но какая верная понятия не имею...

Видимо с тем что индексы используеш 1,2,3 а не 0,1,2

Эти числа я ввожу в EditBox, так что сомневаюсь, что это как-то влияет. А массив считаю с [0..n]

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

Denil-Tornado, буду весьма благодарен! :D

For Loop он не у Array, он сам по себе :) просто позволяет сделать вызов опрделённого участка кода N раз, и обеспечивает тебя информацией о том которая итерация цикла щяс происходит. For each же позволяет тебе достаточно легко и просто перебрать все элементы массива, предоставляет тебе сразу ссылку на очередной перебираемый элемент массива. С помощью первоог можно всегда сделать второе, но наоборот уже не всегда. Вот премер кода который делает одно и то же

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

DimiS, пасиба за совет... кажется я кое-что понял!  :D

Неа... Не сохраняю... Можно поподробнее в этом направлении?  :)  (Блин... тока исходник мега замусоренный моими экспериментами - там ничего не понятно, сделаю заново) >:(

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

Целью моей было сделать меню с приминением ОО на случай сложной структуры этого самого меню, чтобы не делать кучу GUI элементов. Вопросы такие:
1) Правильно ли я понял суть Interface, Class?
2) Есть ли вообще смысл так делать?
3) Как можно сделать то же самое, но эффективнее и проще?

Исходник прилагается

Вот долгожданная ссылка. Думаю чем нибудь да поможет.

Скачать с Letitbit (http://letitbit.net/download/9193.94221f9a41de817614a07d6f9/Primer.rar.html) 50 Mb

Честно говоря не посмотрел твой пример с gui,но на оффоруме есть отличный примерчик,в ветке по конференции.Правда сначала надо разобраться с Examples-OO-Observer.

Denil-Tornado

Спасибо за урок! ;D

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


1) Пока сложно сказать, но мыслиш ты в правильном направлении ;)
2) Конечно есть, я и сам делал подобные вещи в коммерческих проектах
3)Я переделал слегка твой исходник -- ОО структуру + сделал пример использования такого подхода.
Всё это касается в основном того как следует воспринимать Объектно Ориентированое програмирование в целом, не только в квесте. Во первых я разделил понятие GUI элемента и компонента который может содержать в себе какое то сочетание из этих GUI элементов. Я назвал такой компонент MenuItem, для наглядности я добавил в него два слайдера. То, как было сделано у тебя, не позволяло этого сделать, нельзя два раза включить один и тот же интерфейс.
Также я создал интерфейс общий для всех GUI элементов который содержит свойства которые есть у каждого из них -- позиция и размеры(можно там добавить ещё Enabled, Skin). И сделал отдельные интерфейсы для тех свойств которые уже могут различатся, отдельно для EditBox и для Slider. А потом создал классы которые совмещяют необходимые интерфейсы.
Ещё совет, если у тебя есть функция с названием Draw, то пусть она только рисует, не надо там делать какие то ещё посторонние телодвижения. Постарайся так же избегать в функциях какого то локального класса использовать какие то внешние переменные.

Всё что я те тут насоветовал это не аксиома, но жизнь становится проще :)

ПыСы: использование ОО позволяет полностью отказаться от исползования квестовых массивов, и в этом есть куча преимуществ

Ой блин! Спасибо вам ОГРОМНОЕ DimiS (за объяснения, которые убрали мешанину у меня в голове и за переделывание исходника) и Denil-Tornado (за видео урок)!!!
Прям Очень помогли! Мне как раз это надо было! Теперь многое стало ясно!

Всегда пожалуйста, обращайтесь ещё. :D

Всем привет.Разбираюсь с примером Патрикаhttp://forum.quest3d.com/index.php?topic=67133.0

Не могу понять как сделать ObjectUpdate-Override.Если в стандартной схеме все просто-прилепил интерфейс object к любому объекту - override update и делай ,что хочешь,то тут идет ссылка на него.

Если тебе не хватает метода Update, то дорисуй его в интерфейсе Object.
Просто тут объект уже разделен на некоторые составляющие части. Отделяют логику отрисовки объекта от некоторых ресурсов с помощью которых будет отрисован данный объект. Для того чтобы ресурсы можно было подгружать динамически. В данном примере ресурс -- это некая геометрия с некой текстурой и настройками материала. Логика -- это место положения объекта. Object решает в каком месте ему отобразить свою модельку и вызывает метод render у своей модельки с определённым координатами. Важно понимать что вызов 3D Object ченела это просто вызов функции отрисовки геометрии с указаными параметрами: матрица положения, матрица смещения, перечень сюрфейсов(где каждый сюрфейс это тоже структура неких параметров собранных вместе). Сколько раз ты вызовеш 3D Object ченел, столько раз будет выполнена отрисовка.
Если тебе захочется например сделать так чтоб твой объект умел переключать емиссив цвет у своей модельки, ну там для подсветки при наведении мышкой. То надо будет у метода render из IModel интерфейса добавить параметр emissive vector и в каждой подгружаемой модельке приклеить этот параметр в нужном месте. А вот в логике Object-а уже проверять не наведена ли мышка сейчас на него, и рендерить свою модельку с соответствующим параметром.

Привет.Меня инересует Updete-Override т.е.например,разное движение бокса и тора.Т.е.в обычной схеме в интерфейсе iObject я воткннул движение для бокса.И этот интерфейс прилепил к боксу.К тору я воткнул этот же интерфейс,но с Upd-override и приделал свое движение.Здесь же ,видимо,надо слепить отдельные интерфейсы для каждого типам объектов.

Позвольте задать несколько вопросов по теории, дабы лучше все понять!  :)

1) Насколько я понял, то такой странный канал под названием THIS отражает принцип Полиморфизма в ОО? Вопрос собственно такой, правильно ли я понял и можно ли объяснить как это работает, а то чтот не догоняю. Ведь по идее он не нужен, так как объекты определенного класса и так знают, что они это они, а не другие!  :D

2) По идее ОО подход можно применить и без набора инструментов для работы с ОО (просто будет не удобно и долго, что не оправдает ОО)? Ведь это же просто метод такой или я чего-то не догоняю и есть какая-то великая тайна?  ::)

Здраствуйте уважаемые квестовцы, я могу даже разрешить себя отпинать ради получения ответа на свой нубски-ламерский вопрос, чем различаетсе array между ОО ? Конкретно интересует сложность освоения, гибкость использования, удобство использования и производительность (FPS)

THIS это всегда ссылка на тот класс инстанс у которого вызывается этот метод
_Методы_ определённого класса итак знают ссылки на свои объекты только в языках высокого уровня. Им эта ссылка передаётся как неявный параметр, доступ к нему можно получить с помощью ключевого слова this. Просто когда ты обращаешься к методу не указывая у какого класс инстанса её надо вызвать, то компилятор сам подставляет вызов у себя. Так же и со свойствами.
В квесте же нету компилятора как такового, и никто за тебя там сам ничо не подставит, поэтому надо явно указывать у кого ты вызываешь метод.


Тут ты абсолютно прав

Скажите, чем отличается элемент интерфейса Function: ChannelCaller от  Channel Caller ? ???

а где ты его нашёл?

Я знаю что Function: ChannelCaller исползуется для сборки ОО
А Channel Caller используется для зборки голого проекта

Может я чо не так написал, ну вот на скринах покажу:

В первом случае ты назначаешь функцию работы, а во воторм ты чисто используешь канал.

Конечно уже готовиться справка по ОО, но вопросов у меня много, не могу ждать!  :D
В общем был бы очень благодарен, если бы мне на пальцах объяснили зачем нужны так называемые Сеттеры и Геттеры.
А еще есть вопрос такого плана - как мне для объектов одного класса, использующих какую-либо функцию, сделать так чтобы эта функция была разной для каждого конкретного объекта... Ну тут хотя бы в общих чертах...

Экземпляры одного и того же класса не могут иметь разные функции, только данные, в зависимости от которых функция уже может срабатывать по разному.
Разными функции могут быть у одного и того же интерфейса используемого в разных классах.
Если тебе надо чтоб у двух объектов одна и та же функция работала по разному, то создай им разные классы. Определи нужный тебе интерфейс в обоих этих классах, и определи нужную тебе функцию для каждого класса. Когда потом будешь использовать экземпляры этого класса, то обращаться будешь всё так же через общий для них интерфейс, как если бы это был один и тот же класс.

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

Ого! Пасиба Огромное! Мега Информативный ответ!
А срабатывание функции в зависимости от данных объекта делается обычной логикой (ну то есть switch, expression) или есть какие-то особенные прием?

Вопрос не в тему, но быстра ли организация ОО? каким образом она компилируется? создаются ли при этом лишние интерфейсы ?

И стоит ли смотреть на Луа скрипт, для загрузок моделей?

я вобщем не совсем понял про скорость организации ОО -- если ты спрашиваешь о скорости создания ОО структуры то тут от опыта зависит. Компилируеться она как и всё в квесте на лету, или тут я тоже не понял о чём речь. Интерфейсы, ну только те что ты создаёш сам...

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

Да, упустил. Я имею ввиду итоговую производительность ФПС проекта на ОО и ЛУА.

Луа грузит виртуалку (поправьте есле не так), а это не совсем хорошо. ;) Скорее всего я буду использовать ЛУА для загрузок.

ОО, как оно компилируется нет ли при этом лишних процедур

a:=c+b;
interface:=a;
callchenel:=interface;

вместо должного
callchenel:=c+b;

По сути квест - это набор ДЛЛок и связей между ними, т.е. оптимизации на этом уровне не предвидится. Конкретно , что быстрее: caller->interface-> caller или caller-> caller ?
либо одинаково, либо через ОО тормознее.

ОО я хочу использовать уже при рендеринге, т.е. скорость критична.

да, в целом ОО несколько тормознутее чем обычный ченел граф, хотя я почти на 100% уверен, что это изза вызова функций. Так что если постараться обойтись без них, то это несколько ускорит производительность, но с другой стороны тогда это ОО и даром такое не надо.
Переписывая некоторые проги с обычного ченелграфа на ОО у меня получалось падение фпс с 45 до 40. Ну это приблизительно.
Скорость и удобство разработки для меня важнее.

Скажите, пожалуйста, как добавлять\удалять динамически экземпляры класса в контейнер... Какую команду для этого использовать?
Думал, что просто, но почему то не вышло нифига ???