ds29,
да это верно 

ток вот дело в том что например для того чтоб обойти какое то препятствие в пространстве какому то модулю- механизму ..во  первых цвет точки ненужет вовсе ...а во вторых при движени в пространстве достаточна точность плюс минус 1 см ...можно масштабировать изображение ...
возьми кубик со стороной 32*32*32 получается 32768 варианта если чёрно белое изображение (вполне достаточное что  б принять решение есть проход или нет например чёрный нет прохода белый есть ..) если пондобится большая разрешаюсщая способность то пусть точка кодируется не одним битом  а 32 ...и пусть это не цвет будет а адрес ещё одной структуры 32*32*32 но с другим масштабом ...всего делов то ).....ты не заметил совсем ...я предлагаю новый подход к записи информации относительно пространства))....не плоские фигуры рисуют предмет а уже вполне реальное изображение ))сохраняем.. 
Вот на счёт что не захочет нихто с  OpenGL спрыгивать это другое дело )).вообщем так и происходит ...только любое животное на планете легко обходиться без 533 ГГц процессора .....и жёстких дисков огромного размера ))    

Это называется "фотография". Нарисуй в 3d (DirectX или OpenGL) нужный объект и сделай скриншет с окна - задача решена без всяких мудрых алгоритмов.


OpenGL & DirectX были придуманы специально для того, чтобы избавить всех желающих заниматься 3d-графикой от проделанного тобой титанического труда по ручному преобразованию 2d в 3d и обратно. Фактически, можно сказать, что ты написал собственный OpenGL, заточенный под одну конкретную задачу.


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


Разве что в полете. Созданная машина не сможет даже ездить по ей же составленной карте, потому как распознавание изображения - задача сложнейшая, над которой без особых успехов бьются с момента появления систем сканирования 3d-объектов. 

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

Весьма интересно, как ты собираешься узнать, видимы ли области, не перебрав все элементы массива? Или будешь угадывать? 

rsm, т.е. по-твоему для моделования куба размером 1024^3 действительно требуется  536 ГГц? 

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

Подобный "движок" можно написать на Java или C# за один день. Могу поспорить, будет быстрее вашего доморощенного на асме.  

в смысле Подобный "движок" , т.е. с использ. DX or OGL , тогда вермя написания будет примерно равно , если писать на Macro Assenblere.

а "твоих" движков на c# сейчас в сети море и открытыми кодами, так что его никто и писать не будет.

и давайте почитаем книжки 3D гарфики, а то сейчас пойдут споры о z-буФере, проэкциях и т.п. 

* 

Это сообщение отредактировал(а) ds29 - 2.6.2006, 10:57

Java быстрее чем ассемблер? Не смеши мои тапочки...    

Быстрее, чем самодельный движок, написанный не-специалистом. Читай посты внимательнее. 

 

Могу поспорить, что Ваш комплект разработчика на C# нелицензионный. Или што без движка Java/C# вообще ничего не запустицца. И о многом другом могу поспорить.

Имхо, такого рода наезды на ассемблер в данном контексте не вполне тактичны 

 

а бывают не самодельные, или говоря о написании движка на Java или C# за один день ты подразумевал модификацию какого либо движка с открытым кодом?

а где читать внимательнее, процетируй плиз где написано, что не-специалист
?  

Это сообщение отредактировал(а) ds29 - 2.6.2006, 20:45

Для рисования только кубов сойдет и такой алгоритм. Однако РАЗДОЛБАЙ еще в начале указал, что желает применять свою разработку для любых 3d-объектов любой формы. 

Используя готовые библиотеки простой движок можно написать за один день. 


Написано - вашего [движка]. Вроде как не заметил, чтобы автор темы был специалистом в 3D.


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

Не понял.


Это не наезды на асм. Просто идеи, выдвинутые в этой теме (поточечное рисование итп) сделают такой асмовый движок медленнее любого, даже Java-движка, раз в нцать. Из-за незнания основ.  

Здесь я согласен с Domestic Cat. перегнать на асме компилируемые или даже интерпретируемые языки - это не жопки от морковок откусывать. MOV и CMP может написать каждый. Тут нужно специфику современных процессоров учитывать, которая еще постоянно развивается. 

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


S.A.P., в данном случае программирование на Ассемблере и заключается в оптимизации.