GlScene, Objects

← →
VVV-First (2005-05-17 14:44) [0]

Такой вопрос, если я динамически создаю в сцене несколько объктов, то после Scene.destroy освободится память из по них(созданных мною бъектов) , или нужно делать это самостоятельно?

← →
Xeno © (2005-05-19 06:51) [1]

Для освобождения памяти делай Объект.Free, иначе возможно возникновение исключительных ситуауций...

← →
Fosgen (2005-05-19 10:42) [2]

Спору нет Free - безопаснее и к коду менее требовательна, только имеет ряд дырок из-за которых не всегда освобождает память. Destroy в этом плане надежнее, хотя, однозначно придется серъезнее код продумывать.
А Scene.Destroy делать не надо - в процедуру завершения приложения Дельфя сама нужный код добавляет и всю память очищает (по документации, конечно). Memory Leaks правда и там есть.

← →
Xeno © (2005-05-19 12:24) [3]

>VVV-First
Советую какую-нибудь книгу по Delphi, прикупить, там как раз ,в основном, основы подробно разобранны и Free и Destroy и т.д., тогда таких вопросов возникать не будет :)

← →
Ntdstr (2005-05-19 14:26) [4]

Пиздец вы долбоёбы! Такую ХЕРНЮ писать! Да это же каждый ЛАМЕР
знает!

← →
Da Stranger © (2005-05-19 16:26) [5]

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

Что за бред??? Почитай код TObject.Free.
Лучше молчать, чем давать неправильные советы!

← →
Da Stranger © (2005-05-19 17:55) [6]

Кстати, забыл ответить на оригинальный вопрос...
Вся памать, выделенная под любые объекты (как статически, так и динамически созданные), GLBehaviours, GLEffects (присоединённые к объектам GLScene) освобождается достаточно корректно. Смотрите в TGLScene.Destroy и в TGLBaseSceneObject.Destroy, если не верите.
Автоматически НЕ удаляются объекты, которые можно найти на "Component palette", включая менеджеры эффектов и GLSceneViewer, GLMaterialLibrary и др.

Когда же вы наконец-то научитесь смотреть исходники перед тем, как задавать вопросы... Use the source, guys!!!

← →
Fosgen (2005-05-30 09:46) [7]

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

← →
Xeno © (2005-05-30 10:31) [8]

Da Stranger © (19.05.05 17:55) [6]

>Вся памать, выделенная под любые объекты (как статически, так и
>динамически созданные), GLBehaviours, GLEffects (присоединённые
>к объектам GLScene) освобождается достаточно корректно.

Позвольте не согласиться,далеко ходить не надо,в GLScene присутствует
TGLPerlinPFXManager и TGLParticleFXRenderer,освобождение памяти, при их интенсивном использовании, иногда вызывает исключительные ситуации,причём чаще всего всё работает нормально до выгрузки приложения, код не привожу,но думаю те кто пробовал их использовать в своих проектах должны были с этим столкнуться, хотя допускаю мысль что я сам что-то неправильно сделал.

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

← →
Fosgen (2005-05-30 11:42) [9]

2 Xeno : Полностью согласен с ситуацией по поводу TGLFreeForm и загруженными 3DS моделями именно с таким положением вещей я и сталкивался... Правда не выяснил что это именно из-за маппинга...

← →
Xeno © (2005-05-31 06:30) [10]

>Fosgen
Могу добавить, что вероятность возникновения глюка с TGLFreeForm и 3DS наиболее сильна при загрузке некоторого числа моделей(с использованием маппинга) с одинаковой текстурой...

← →
Fosgen (2005-05-31 08:52) [11]

2 Xeno : Пока что не наступил на таковые грабли, но за предупреждение - благодарю. Использую исключительно модели в 3DS, потому как анимированные мне не требуются (по крайней мере на данном этапе), все модели с маппингом, все грузятся во FreeForm. В среднем число моделей в сцене от 20 до 100. Но это пока я некоторые модули доделаю... Динамика объектов довольно большая даже в таком диапазоне.
Да, извиняюсь за оффтоп, никто не сталкивался с задачей отключения Z-buffer (depth test) перед рендерингом СПРАЙТОВ в GLScene? Меня интересует скорее как это вставить в процесс рендеринга. Потому как все остальные объекты должны с буфером глубины обсчитываться... Если Вас не затруднит - подбросьте мысль, али намекните.

← →
DeadMeat © (2005-05-31 19:15) [12]

NoZWrite...
glDisable(GL_DEPTH_TEST); с учетом http://delphimaster.net/view/9-1117520325/&web=1

---
...Death Is Only The Begining...

← →
Fosgen (2005-05-31 22:58) [13]

2 DeadMeat: Это конечно приятно. Спасибо за ответ, в принципе непосредственно с командами OpenGL я знаком, но все-таки неясно как разделять (на уровне DirectOpenGL), сваленные в одной куче (на уровне GLScene) объекты компилируемые с DepthTest и спрайты компилируемые без? А ведь именно в ЭТОМ вся загвоздка... OnRender событие одно. Компилится в нем все - как отделить мух от котлет? Причем ввиду динамически перестраиваемой сцены последовательность и тех и других непредсказуема...

← →
Домовенок © (2005-05-31 23:19) [14]

> Fosgen (31.05.05 22:58) [13]

> Компилится в нем все - как отделить мух от котлет?

Мухи это мухи, а котлеты это котлеты. Так же и в твоем случае, спрайты это спрайты, FreeFormы это FreeFormы. У каждого объекта есть ClassName можно по нему проверять что есть что – но это не очень удобно. Так же можно для каждого типа объектов задавать свой номер в свойстве Tag после чего уже определять по номеру в Tag что есть что. Еще очень полезно разбивать разные типы объектов в разные DummyCubes что бы потом можно было легко что-то найти. К примеру:

Есть 3 модели ящика и 5 модели бочки, помещаем ящики в DummyCube1, а бочки в DummeCube2. Допустим, нам понадобилась какая то бочка, ты сразу знаешь, что у тебя бочки в DummyCube2, остается только перебрать все содержимое DummyCube2 и определить какая из всех тамошних бочек является нужной тебе. В таком случае тебе не придется перебирать все ящики и проверять является ли этот ящик нужной тебе бочкой. Думаю, что этот пример поможет с экономить множество лишних проверок.

← →
Fosgen (2005-05-31 23:51) [15]

2 Домовенок : Спасибо, этим уже давно пользуюсь, как и организацией своих классов и т.д., да вот только в DirectOpenGL это мало помогает или я что-то туплю. Разговор идет о классификации рендеренных объектов при исполнении события OnRender компонента DirectOpenGL в GLScene. Если я ничего не путаю... В частности надо перед рендерингом объектов класса TSprite вырубать DepthTest. Какой командой выключать я знаю. Уже знаю что это можно сделать в событии OnRender, но вот как это сделать ТОЛЬКО для СПРАЙТОВ? Причем вариант с превентивной организацией не про меня - у меня вся сцена динамически генерится, меняется каждую секунду и в разные DummyCube мне объекты даже по какому-то одному признаку заталкивать - не подходит... Хоть бы кусок кода привел хто-нить что ли...

← →
XProger © (2005-06-01 00:23) [16]

TParticle = class ... procedure Render; virtual; end; TSprite = class(TParticle) ... procedure Render; override; end; TSpark = class(TParticle) ... procedure Render; override; end; procedure TSprite.Draw; begin glDisable(GL_DEPTH_TEST); ... glEnable(GL_DEPTH_TEST); end; procedure TSpark.Draw; begin ... end; var Obj : array of TParticle; begin SetLength(Obj, 2); Obj[0] := TSprite.Create; Obj[1] := TSpark.Create; ... for i := 0 to Length(Obj) - 1 do Obj[i].Draw; end;

← →
XProger © (2005-06-01 00:27) [17]

Draw замени на Render :o)

← →
DeadMeat © (2005-06-01 01:09) [18]

Я так и не понял, почему NoZWrite не подходит...

---
...Death Is Only The Begining...

← →
Fosgen (2005-06-02 09:20) [19]

2 XProger: ВААУ! СПАСИБО! Однако... Правда туплю - заменить один из методов класса... То ли смелости, то ли ума не хватило...

← →
Fosgen (2005-06-04 09:40) [20]

Приношу всем свои искренние извинения - тупил несколько недель по пустяковому вопросу. Спасибо всем, особенно DeadMeat, который вывел мои мозги из тупикового периода - разумеется NoZWrite - именно то св-во, что мне и требовалось. Однозначно благодарю всех, проявивших интерес к моей задаче.
2 XProger: Как ни печально, но предложенный (не лишенный заманчивости) вариант с override процедурой класса не проходит, ибо метод Render - как выяснилось не virtual...

Fosgen, это можно использовать в качестве надстройки над GLScene %)
А вообще написание всего ручками пойдёт тебе только на пользу...

← →
Fosgen (2005-06-05 11:39) [22]

2 XProger: Я вообще много чего пишу ручками, но в данном случае проверено - как надстройка это не будет работать, поскольку у класса TGLBaseSceneObject метод Render не является виртуальным, таким образом override сделать ему никак нельзя - разве что исходники GlScene править,вот только не знаю к каким эффектам это приведет - у меня сейчас немного другая задача...

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

Увыжаемый, Fosgen! Вы написали, что Destroy надёжнее, чем Free. Опять же повторюсь, что это бред (со ссылкой на процедуру TObject.Free) Насчет оптимизации с работой с паматью - c этим трудно не согласиться... Но по крайней мере работа с памятью более безопасная, чем в C++ ;)

> Позвольте не согласиться,далеко ходить не надо,в GLScene
> присутствует
> TGLPerlinPFXManager и TGLParticleFXRenderer,освобождение
> памяти, при их интенсивном использовании, иногда вызывает
> исключительные ситуации,причём чаще всего всё работает нормально
> до выгрузки приложения, код не привожу,но думаю те кто пробовал
> их использовать в своих проектах должны были с этим столкнуться,
> хотя допускаю мысль что я сам что-то неправильно сделал.

TGLPerlinPFXManager - это менеджер эффектов, о которых я упомянул. А об исключительных ситуациях - их действительно GLScene обрабатывает нелучшим образом и скорее всего память после этого не освобождает. А чтобы избежать ошибок при закрытии приложения надо делать Cadencer.Enabled:=false? это часто помогает.

Fosgen,
TSprite = class(TParcicle) constructor Create; destructor Destroy; override; public Obj : TGLBaseSceneObject; procedure Render; override; end; ... procedure TSprite.Render; begin Obj.Render; end;
Вах! Какая надстройка! ;)

← →
Fosgen (2005-06-07 10:00) [25]

2 XProger: Однако... Интересный подход... Попробую на досуге. Не совсем ясна идея с TGLBaseSceneObject в качестве Property, но поразмыслю... Загрузил, спасибо.

← →
П7 (2005-06-07 11:04) [26]

> Fosgen (07.06.05 10:00) [25]

А это не проперть... (:

← →
Fosgen (2005-06-07 16:23) [27]

2 П7 : А шо же это такое? Метод что ли? И всяко не родитель и не потомок... Третьего - не дано в любом варианте...

← →
П7 (2005-06-07 16:53) [28]

дыну? а я думал что проперть - это:
CMyClass = class private FValue : integer; public property Value : integer; read FValue; end;
Или как там эта гадость пишется... (:

>Da Stranger

>TGLPerlinPFXManager - это менеджер эффектов, о которых я >упомянул. А об исключительных ситуациях - их действительно >GLScene обрабатывает нелучшим образом и скорее всего память после >этого не освобождает. А чтобы избежать ошибок при закрытии >приложения надо делать Cadencer.Enabled:=false? это часто >помогает.

Cadencer.Enabled:=false - Иногда помогает,но чаще,к сожалению нет. Это было самое первое что я пробовал что-бы исправить проблему :) Выход я нашёл только один, сочетания кода, вызывающие исключительные ситуации, просто не использую...

GlScene, Objects Найти похожие ветки