Pull to refresh
0
0
Олег@GigaCore

https://blackcore.technology/

Send message

С JIT как раз можно производить profile guided рекомпиляцию, причем С++ код тоже можно джитить ( смотреть llvm )

А зачем покупать топовый MacBook Pro на m1 max?

потому что изготовление всех моделей идет из полигонов или воксели-полигоны
Для турбуленции используют ротор(curl) от векторного поля, сконстурированного из нескольких шумов перлина с разными сидами (во всех коммерческих симуляторах дыма )
http://www.cs.ubc.ca/~rbridson/docs/bridson-siggraph2007-curlnoise.pdf
результирующее векторное поле сил обладает нолевой дивергенцией (т.е. не генерирует и не убавляет скорость суммарно по контейнеру)

Так почему она проверяется даже когда никогда не нужна ?

Притом 35 это для одного канала (при указанной частоте), коих у 9900 два.

любая полигональная модель можен быть использована для генерации разреженной, адаптивной воксельной сетки, где будет храниться sdf.
www.openvdb.org/download
все примеры внизу, которые выглядит как полигональные — на самом деле sdf
Подскажите пожалуйста, интеловская реализация Openmp поддерживает больше чем 64 потока под windows у вас? Используете ли вы numa-aware аллокаторы?

Никак. Из центра ячеек виртуальные частицы назад во времени трассируются, затем в месте «приземления» линейной интерполяцией по окружающим ячейкам забирается значение (скорости и остальных полей).

Они не создаются в явном виде, а сам метод нужен для стабильного решения с любым сколь угодно большим шагом по времени. У конечно-разгстных схем cfl ниже единицы почти везде, что очень печально для скорости. Оригинальный папер по этому методу:
https://www.researchgate.net/publication/2486965_Stable_Fluids

какого плана заготовки интересуют? тут например достаточно читабельные исходники для решения слау из пуассона сопряженным градиентом:
wavelet turbulence
на мой взгляд сильнее всего влияет слишком большой cfl, который нужно сильно уменьшать хотя бы до 2-3, ну и итерации на солвере давления конечно тоже делают свой вклад. вязкость наоборот блюрит детализацию, я бы отключал её вовсе.
это и есть общепринятая терминология в контексте жидкостей в компьютерной графике) Метод не эйлеров, а полулагранжевый (semi-lagrangian), виртуальные частицы трекаются из вокселей назад во времени. Но соглашусь, оригинальные статьи из gpu gems нвидиевских очень плохи и крайне сумбурны, ещё и с ошибками когда я последний раз туда смотрел
совет наинающим — если не собираетесь в анимацию, учите какой угодно софт, только не этот
А как вы получили гпу арнольд? я знаю что он сейчас в чем-то вроде закрытой beta, не могли бы вы у своих узнать сложно ли выбить доступ от компании? Буду благодарен
Что за рендер, который и на цпу и на гпу, и что бы до сотен раз быстрее на гпу?
Как я понимаю, спрашивать как бы эта сцена диснеевская (или иная киношная) поместилась в память гпу не стоит?
Речь шла про перспективы в будущем, а про миллисекнуды на перестройку всей сцены это репорты из ресерчей ~2011 года hlbvh2 2011
Разбиение пространства давно уже производится за считанные миллисекунды прямо на гпу, начиная с lbvh, как крайне высокопараллелизируемого варианта bvh. Чистая трассировка очень хорошо подходит для гпу, проблемы идут в основном на сложных материалах.
В гудини. Если рассматривать плагины, то феникс, фумфх и особенно turbulence fd (под синему). Насколько я помню, майский модуль флюидов был первым публично доступным солвером года эдак около 99 (99ым датирована научная работа автора этих флюидов, в которых он и упомянул что его солвер ушел в майку) и с тех пор газовая часть особо не менялась. Медленно, негибко — это все про него. Бифрост пока что сырой, всего лишь часть из того, что было в naiad и непонятно, когда они реализуют все обещанное. Что касается жидкостей, то бифрост заточен под large scale симуляции, т.е. океаны, реки, крупные всплески. Сделать красивый всплеск для пакшота или ещё что-то, где проявляется сильное поверхностное натяжение значительно легче в рилфло pbd/sph солвере и ему подобных (бифрост это FLIP)

флюиды в maya это чертовски слабая сторона

Information

Rating
Does not participate
Location
Харьков, Харьковская обл., Украина
Date of birth
Registered
Activity

Specialization

Десктоп разработчик, Разработчик приложений