Render.ru

правка риба на лету...

N

Narvi

Активный участник
#1
Рейтинг
11
#1
Я не знаю в каком состоянии сегодня рибоправящая промышленность, но у меня вроде получилось решить проблему многократного вызова неуникального скрипта. Тоесть в сцену можно подключить несколько инстансов скрипта с одинаковоми параметрами вызова...

ЗЫ Если это кому нужно и я не изобрел велосипед, то пишите - покажу...

ЗЫЗЫ Просто вроде не очень экономно на 1000 примитивов вызывать 1000 перлов;) Можно обойтись одним...
 

Guest
#3
#3
ЭЭЭЭ, а можно кратенько но убористо на форум :)

На пример:

1. Самый "краткий" - из работающих перл скриптов...
2. Самый маленький - Rib файл с вызовами (ascii формат)


Ну и и если можно все это на ftp и в zip архив ... Всем будет очень приятно ...

Если нет ftp можно конкретно мне по почте .. Не откажусь ... :)
 

Guest
#4
#4
Первое, что мне приходит в голову - написать чего-то типа сервера на перле, которое бы принимало коннекты из DSO и по ним запускало внутри себя нужный скрипт. Поскольку осознать предыдушую фразу, а тем более её реализовать - сложно - то просим делатей вашего солюшна :)
 
N

Narvi

Активный участник
#5
Рейтинг
11
#5
Ой;) Нет, все гораздо проще... Дело в том, что фраза из документации "program must be written in a loop" означает, что программа должна выдавать по куску риба в ответ на каждую строчку прилетающую по STDIN, а завершаться только когда по STDIN прилетит EOF. Тоесть рендерман запускает наш скрипт и ожидает что тот ему будет выдавать геометрию разной детальности для разных размеров на экране, которые он выдает ему через STDIN. А если этого лупа нет, то первый вызов проходит удачно, а когда рендерман пытается спросить программу про такой же примитив но с другой по его мнению детальностью, то вылетает, поскольку программа завершила свою работу... Вообщем, скрипт должен иметь следующий вид:

while (<STDIN>)
{
/Здесь идет кусок риба, который хотите видеть на экране/
print "\377";
IO::Handle::flush(STDOUT);
}

Могу послать на мыл, мой скрипт который реализует вышеуказанный принцип и работает...;)
 

Guest
#6
#6
А то как то мутно пока.
Скрипт запускается в Procedural "RunProgram" или в Custom Render?
 
N

Narvi

Активный участник
#7
Рейтинг
11
#7
Да... Как Procedural "RunProgram". Все то же самое, как в примере, который приводил Харитонов, только надо добавить loop по <STDIN> и в конце выгонки риба, после print "\n\377 добавить IO::Handle::flush(STDOUT);

Пример ща пошлю на мыл...
 

Guest
#8
#8
А выложите полиз куданибудь на сайт ... (ну в том виде корторый я упоминал ваше) ...
Или если можно мне на мыло ...
Я выложу сам.... Тогда ... :)
 

Guest
#9
#9
for ($i = 0; $i <= $#$NumG; $i++)
...
print "Procedural \"DelayedReadArchive\" $myGeom $myBound \n";
}
print "\377";
IO::Handle::flush(STDOUT);

...нас ведь уже вызвали для заданного Bound, при вызове RunProgram
и от нас ожидают уже геометрии на выходе. Зачем же тогда опять
DelayedReadArchive с $myBound подставлять?
Можно ведь rib прочитать и в stdout выбросить.
 

Guest
#10
#10
Правильный код - я его повторю здесь - такой:

while (<STDIN>)
{
/Здесь идет кусок риба, который хотите видеть на экране/
print "\377";
IO::Handle::flush(STDOUT);
}

Никакого повторного вызова DelayedReadArchive, естественно, нет.

Кстати, Нарви, вместо IO::Handle::flush(STDOUT); вполне можно в начале скрипта ставить

$| = 1; # Force unbuffered STDOUT and STDIN.

И таким образом просто выключать буфер. Правда, непонятно, как сие повлияет на скорость выполнения - вполне возможно, что всё буферить, а потом буфер сбрасывать будет быстрее, чем не буферить ничего.

Кстати, фокус с $| = 1 есть в каждой книжке по Perl и программированию в вебе. Там тоже очень важно - чтобы страница в буфере не застряла :)
 

Guest
#11
#11
To Kidd:
Я привел выдержку из скрипта, что прислал Narvi.
Может не совсем полную и поэтому непонятки.
Думаю Narvi не будет против если приведу фрагмент целиком.

while (<STDIN>)
{
for ($i = 0; $i <= $#$NumG; $i++)
{
$myGeom=$manBase->{"$curType"}->{"Geom"}->[$i];
$myBound= $manBase->{"$curType"}->{"Bound"};
$myShader= $manBase->{"$curType"}->{"$Shaders->[$i]"};
print "$myShader\n";
print "Procedural \"DelayedReadArchive\" $myGeom $myBound \n";
}
print "\377";
#$io->flush(STDIN);
IO::Handle::flush(STDOUT);
}

To Narvi:
Как предположил Kidd
>Никакого повторного вызова DelayedReadArchive, естественно, нет.
А он таки в коде есть. Может это дань красоте синтаксиса :)
Но по семантике мне кажется, что в этом месте уже можно и содержимое
архивов выдать в поток, а не напрягать рендер еще одним DelayedReadArchive с новыми Bounds.Или в этом какой то скрытый умысел?
 
N

Narvi

Активный участник
#12
Рейтинг
11
#12
Вообщем, можно... Но мне показалось так будет круче;) На самом деле мне это было нужно, чтобы было проще отлаживать. Хотя сакральный смысл в этом, вся же, я думаю можно найти... Я сильно подозреваю, что PRMAN'у будет легче прочитать риб с диска, чем перлу прочитать его с диска и отправить в стдин. Так ведь получается что ПРМАНу прилетает нра стдин строчек пять, вместо целого риба... В принципе, я думаю можно обойтись простым ReadArchive. Но с другой стороны, теоретически возможна ситуация когда пол-обьекта, генерируемого скриптом на экране, вторая же за...

Правда, на сколько рендереру проще прочитать ReadArchive вместо DelayedReadArchive?
 

Guest
#13
#13
... писал prman, то эти процедуры шарили бы код, и поэтому читали бы файлы с одинаковой скоростью. Более того - это была бы та же самая скорость, с которой читает файлы Perl.

Было бы гораздо интереснее, если бы either prman or Perl под виндой использовали навороты операционки по быстрому доступу к файлам (типа memory mapped files). Но увы - Перл точно не использует (я смотрел в сорцы). prman, судя по всему - тоже, поскольку менять парадигму кода они вряд ли бы стали...
 
Сверху