В каком смысле оба? Кривая Безье это более общий случай чем кубический сплайн. Я прикинул коэффициенты, получилось что для того, чтобы она выродилась в обычный кубический сплайн надо опорные точки разнести по x на треть расстояния. Уже после этого подбирать коэффициенты по Эрмиту или как нибудь ещё. В примере же половина.
Просто был какой-то древний редактор (DrHalo) который со всем этим замечательно справлялся, но я что-то так и не понял как, несмотря на многочисленные эксперименты.
Так и надо сделать их равными, тогда при масштабировании они останутся равными. А углы при вертикальном масштабировании перестают быть равными. Это правильно для графика. Я использовал равенство углов в редакторе, так как там более важно было то, что картинка правильно ведёт себя при вращении, хотя при этом получалась проблема при разном изменении масштаба по каждой оси.
Есть идея провести один отрезок вертикально из В1 на АВ, а другой из С1 на АС и требовать равенства этих отрезков а не углов, и может тогда всё будет масштабироваться правильно.
Там видимо не углы надо равными делать, а что-то другое, тогда и точки не надо пересчитывать. А на вашем конкретном графике вроде вообще не особо заметно что углы меняются и кажется что всё почти О'К
Мне кажется, что уже просто то, что при масштабировании по вертикали какие-то углы перестают быть равными и надо все перестраивать, говорит что для построения графика это не особо подходит. График не должен как-то дополнительно изменяться помимо самого масштабирования. А вот на рисунках это не выглядит проблемой. А то порой приходится все эти узлы каждый раз двигать у каждого стыка когда рисуешь с использованием кривых Безье.
Я тогда решил, что форма не должна меняться, так что после расчёта при заданном масштабе всё приводилось в такой вид, чтобы после изменения масштаба форма не менялась, хотя углы уже переставали быть равными. Для меня так было удобнее, тем более что я там ещё какой-то метод построения кривых Безье использовал. Давно это было, в те времена когда inkscape был мне не доступен и приходилось выкручиваться чтобы в статью картинку вставить не нарушая никаких лицензий.
Я когда-то такую идею с равными углами встроил в свой векторный редактор… и через некоторое время осознал, что если картинка масштабируется по разному по Y и по X, то кривая вместо такого-же изменения масштаба должна поменять форму, если хочется чтобы углы между касательными остались одинаковыми. Но так как других идей так и не придумал, то всё оставил как было. Не знаю, можно ли тут что-то другое предложить.
Вроде понял, «солнце» у них для земных условий. Чтобы приблизительно моделировать тени можно точечный источник использовать единицах в 100 от объекта, иначе интенсивности не хватит.
Но там же явно видны тени от элементов конструкций, а на рендеринге их нет. Правда у меня на панораме неоправданно яркий Млечный путь и от него может идти дополнительная засветка.
И там ещё про тени внизу в комментарии верно подметили. У меня создаётся впечатление что Cycles пытается рендерить рассеяние в атмосфере, но не понял, как это отключить.
Вот, я просто заменил плоскую картинку из вашего файла на HDRI панораму не особо хорошего качества, которую когда-то сгенерировал для проверки скриптом на POV-Ray (при этом даже такой занимает около 70 Мб) и использовал Cycles
с 100 сэмплами, что-то около часа. Другие варианты (YafaRay, LuxRender) для последней версии blender у меня просто не установлены за ненадобностью, я их тестировал на каких-то предыдущих версиях.
Ещё пара моментов. Я выше написал, почему думаю, что эта сцена в принципе не будет правильно выглядеть, стоит ли тестировать без переделки? И второе, посмотрите на sketchfab модели того-же helijah (это один из разработчиков FlightGear) и какие-нибудь ещё профессионально сделанные сцены — возникает вопрос, если такого хорошего качества можно добиться даже в режиме реального времени, может и правда лучше разобраться с правильной разработкой сцены, не надеясь что машина всё за нас сделает если её подольше заставить поработать?
У меня железа нет под GPU rendering, а POV-Ray из-за своей эффективности все ядра так подвешивает, что другими задачами уже не займешься, а мне и работать надо.
Ну как же про них могут мало знать, если они прямо в дистрибутиве а остальные надо ставить. Да и рекламируют они его активно. Я вообще несколько перепробовал но в основном использую belnder render. Мне кажется как раз Cycles иногда используют напрасно.
Вот в вашем варианте геометрия как раз такая, что Cycles может раскрыть нежелательные вещи — у вас же модель в пустом пространстве висит рядом с картинкой, если какие-то пути дополнительные считать, это не приводит к правильному распределению освещения. Я поэтому и написал про модель с круглой Землёй под кораблём и звёздным куполом над ним. Вот тут пересчёт множества путей был бы обоснован.
с 100 сэмплами, что-то около часа. Другие варианты (YafaRay, LuxRender) для последней версии blender у меня просто не установлены за ненадобностью, я их тестировал на каких-то предыдущих версиях.
Вот в вашем варианте геометрия как раз такая, что Cycles может раскрыть нежелательные вещи — у вас же модель в пустом пространстве висит рядом с картинкой, если какие-то пути дополнительные считать, это не приводит к правильному распределению освещения. Я поэтому и написал про модель с круглой Землёй под кораблём и звёздным куполом над ним. Вот тут пересчёт множества путей был бы обоснован.
Дополнительная проблема в том, что Cycles пока ещё в стадии разработки и есть другие решения, хотя и не «из коробки» об одном из которых я и написал.