Здравствуйте, Varavva, Вы писали:

V>>>Например, человек редактирует сплайн, который является контуром вазы. И сразу видит сбоку эту самую вазу
W>>Это должно выглядеть как на второй минуте этого видео, или как?

V>Так, но немного не так. РИсование линии идет непрерывно, а не кусочками, Поэтому перестаивать 3D придется слишком часто.
Ну не чаще чем раз в кадр. Да и незачем перестраивать — нужно лишь добавлять к уже построенному.

V>И вид трехмерного тела нужен просто сбоку
А это «не сбоку» что-ли? :)
Или ты имеешь ввиду, что ось зрения камеры расположена перпендикулярно плоскости на которой нарисован сплайн, да?

Для честной визуализации лет этак 35 назад описали bump mapping. Собственно, для такой проекции все формулы там получаются крайне простыми. Так что такие изображения строятся легко даже на очень слабых процессорах безо всяких gpu ускорителей (можно найти примеры в старой demoscene, например). Причём это даже для произвольного тела, а уж для поверхности вращения можно сделать ещё кучу оптимизаций: так одна производная будет константой для целой строки изображения, а две другие для тела вращения можно эффективно считать через алгоритм Брезенхема. В целом, на CPU получится супер-быстро и при этом с достаточно честным освещением (всё, кроме теней от тела). И никакого 3d, настоящий old-school безо всякой новомодной арифметики с плавающей точкой (и это уж не говоря об полном отсутствии тригонометрии) :)

Выглядит результат так:

Исходный сплайн справа, а результат bump mapping слева.
Или то же самое в анимации с меняющимся сплайном:



V>- потому и ищу более простые методы, без построения самого тела
Так если тебя интересует простота кода — то делай в 3d. Да, это неэффективно с точке зрения расхода памяти и времени процессора. Но зато код короткий, простой, и пишется быстро. Bump mapping с Брезенхемом работает, конечно, быстрее и тратит намного меньше тактов. Но оно тупо проиграет по количеству строчек кода. Это лет 20 назад ситуация была бы обратной.