| *** rendero has quit IRC | 00:53 | |
| *** Pseudonym has joined #Aqsis | 01:21 | |
| *** cgTobi sets mode: +vv Pseudonym |rt| | 01:38 | |
| cgTobi | hi Andrew | 01:38 |
|---|---|---|
| Pseudonym | G'day. | 01:41 |
| *** scorp007 has joined #aqsis | 03:01 | |
| scorp007 | hi | 03:17 |
| cgTobi | hi Alex | 03:17 |
| *** cgTobi sets mode: +v scorp007 | 03:17 | |
| scorp007 | I have a query: If I render a box as a sub-div, should it look like this? http://img112.imageshack.us/img112/9296/maxtorsubdiv1ro5.jpg | 03:20 |
| scorp007 | hi cgTobi | 03:20 |
| scorp007 | more specifically, a cube | 03:21 |
| cgTobi | hm, I think so | 03:21 |
| scorp007 | I'd have thought it should result in a sphere? | 03:21 |
| scorp007 | this is the archive for the box: http://rafb.net/p/N4Zapx72.html | 03:22 |
| cgTobi | I guess that depends on the hardness of the edges | 03:22 |
| scorp007 | I didn't specify any such parameters though | 03:22 |
| cgTobi | I wouldn't expect a perfect sphere | 03:22 |
| scorp007 | I just tried in RfM, and it gives a perfect sphere | 03:23 |
| scorp007 | which is why I am conmfused | 03:23 |
| cgTobi | oh | 03:23 |
| cgTobi | with the same sice of the cube? | 03:23 |
| scorp007 | yes | 03:23 |
| cgTobi | size | 03:23 |
| scorp007 | I should try Liquid so I can see the generated rib code | 03:23 |
| scorp007 | do you have liquid set up? | 03:24 |
| cgTobi | that might be worth it | 03:24 |
| cgTobi | no, sorry | 03:24 |
| cgTobi | we don't use liquid here | 03:24 |
| scorp007 | ok, will have to install it | 03:24 |
| scorp007 | do you use RAT there? | 03:24 |
| cgTobi | nope | 03:24 |
| cgTobi | some inhouse tool | 03:24 |
| scorp007 | ok | 03:24 |
| scorp007 | for translating maya->renderman? | 03:24 |
| scorp007 | brb | 03:30 |
| *** scorp007 has quit IRC | 03:30 | |
| Pseudonym | I reckon everyone has an in-house tool to convert Maya to RenderMan. | 03:39 |
| Pseudonym | Even if it's only a hacked-up version of someone else's | 03:39 |
| cgTobi | that's certainly true, at least for lager studios | 03:45 |
| cgTobi | larger | 03:46 |
| *** scorp007 has joined #aqsis | 03:52 | |
| scorp007 | Aha, I found the problem | 03:52 |
| scorp007 | Liquid (and presumable RfM) export the cube as quads, I export as tri's | 03:53 |
| scorp007 | presumably* | 03:53 |
| *** cgTobi has quit IRC | 05:05 | |
| *** cgTobi has joined #Aqsis | 05:12 | |
| *** ChanServ sets mode: +o cgTobi | 05:12 | |
| scorp007 | w00t! I fixed it! | 05:13 |
| scorp007 | I rewrote the whole geometry export routine to use polymeshes instead of tri meshes | 05:13 |
| scorp007 | now my subdivs look nice and smooth, like RfM/Liquid | 05:13 |
| cgTobi | wow, nice one | 05:13 |
| scorp007 | and nothing seems borked yet, (s,t work) | 05:14 |
| scorp007 | yep, all works :) | 05:16 |
| scorp007 | hey, guess what! | 05:21 |
| scorp007 | Aqsis now renders the teapot without any of those triangulation artefacts :) | 05:21 |
| scorp007 | this looks like a win for everyone | 05:21 |
| cgTobi | :D | 05:21 |
| *** cgTobi sets mode: +v scorp007 | 05:21 | |
| scorp007 | except pixie, who doesn't recognize facevertex normal N | 05:22 |
| scorp007 | I'll let em know | 05:22 |
| scorp007 | time to build a 64bit version... | 05:25 |
| scorp007 | this is how it should look :) http://img72.imageshack.us/img72/6332/maxtorsubdiv2or5.jpg | 05:34 |
| cgTobi | ah, hehe, makes sense now | 05:34 |
| scorp007 | much nicer, I think :) | 05:35 |
| scorp007 | w00t! my export routine as a side effect runs *even* faster! | 05:44 |
| scorp007 | my head now takes 2.4 secs instead of 3.5 or so | 05:44 |
| scorp007 | ah, I crashed aqsis on some motion blur, hmmm | 05:59 |
| scorp007 | Errm, I get some linker errors when trying to build the latest svn, is that normal? | 06:47 |
| scorp007 | for your reference: http://rafb.net/p/MyO9lh42.html | 06:49 |
| scorp007 | Raytracing in maxToR: http://img169.imageshack.us/img169/7272/maxtorraytrace1ka3.jpg | 07:46 |
| *** pgregory has joined #aqsis | 08:03 | |
| *** ChanServ sets mode: +o pgregory | 08:03 | |
| pgregory | morning all | 08:04 |
| cgTobi | morning Paul | 08:07 |
| cgTobi | on my way home now | 08:07 |
| cgTobi | cya | 08:07 |
| pgregory | hi Tobi | 08:07 |
| pgregory | working nights again? | 08:07 |
| cgTobi | last night today, than I'm evening shift | 08:08 |
| *** cgTobi has quit IRC | 08:11 | |
| scorp007 | hi Paul, brb, eating. (Is aqsis known to be broken in the svn trunk?) | 08:17 |
| *** AlexK has joined #aqsis | 08:17 | |
| pgregory | scorp007: in what way 'broken'? | 08:22 |
| *** Pseudonym has quit IRC | 08:31 | |
| scorp007 | [15:44] <scorp007> Errm, I get some linker errors when trying to build the latest svn, is that normal? | 08:32 |
| scorp007 | [15:46] <scorp007> for your reference: http://rafb.net/p/MyO9lh42.html | 08:32 |
| pgregory | no, not sure why that would be | 08:33 |
| pgregory | on Windows I presume? | 08:33 |
| scorp007 | yes | 08:34 |
| pgregory | which compiler? | 08:34 |
| scorp007 | I did a clean build | 08:34 |
| scorp007 | msvc | 08:34 |
| pgregory | scorp007: odd, bitvector.cpp hasn't changed since June 2006 | 08:35 |
| pgregory | I suspect something might have changed on your system. | 08:35 |
| scorp007 | hmmm | 08:35 |
| pgregory | oh, and bitvector.cpp doesn't reference anything called __security_check_cookie according to my understanding, and that function looks questionable. | 08:36 |
| scorp007 | ahh!! | 08:36 |
| scorp007 | Its using the 64bit build environment! | 08:36 |
| scorp007 | crap | 08:36 |
| scorp007 | somehow it is cached, it shouldnt be | 08:37 |
| scorp007 | how would I reference environment variables in the scons file? | 08:38 |
| scorp007 | I.e. if I have the platform sdk at %PSDKHOME% | 08:38 |
| scorp007 | if at all possible? | 08:39 |
| pgregory | os.environ | 08:39 |
| pgregory | see line 89 in SConstruct | 08:39 |
| scorp007 | but wouldn't it be fine to just use %VAR% since it goes straight to the command line? | 08:40 |
| pgregory | no idea | 08:40 |
| scorp007 | (for my custom.py) | 08:40 |
| scorp007 | ok, I'll try | 08:40 |
| scorp007 | hmm, do you have any idea how scons 'remembers' what cl.exe I used? | 08:42 |
| scorp007 | I want it to forget :P | 08:42 |
| pgregory | Not entirely sure, I think the main toolset identifies the 'most appropriate' one. | 08:43 |
| scorp007 | hmmm | 08:43 |
| scorp007 | BTW, Paul, don't know if you read the logs, but Aqsis no longer has triangle artefacts on teapots (I rewrote my geometry export routine) | 08:45 |
| pgregory | scorp007: what was the problem? | 08:46 |
| scorp007 | I now export as N sided polygons instead of always tris | 08:46 |
| pgregory | so it's a triangles thing then, that makes sense. | 08:46 |
| scorp007 | it also fixed SDS's | 08:46 |
| scorp007 | they used to look lumpy, now I get a perfect sphere from a cube | 08:47 |
| pgregory | hmm, not for SDS though | 08:47 |
| pgregory | scorp007: wellll, not quite, you won't get a sphere from a cube using CC SDS. | 08:47 |
| scorp007 | well, almost, before I had some irregular tumour like shape | 08:47 |
| pgregory | I can understand why tri's would give a bad SDS on Aqsis though. | 08:47 |
| scorp007 | pgregory, no, the SDS looked irregular on every renderer | 08:48 |
| pgregory | we currently don't push to the limit surface when we have to use subdivision all the way, which will introduce inconsitencies. | 08:48 |
| scorp007 | I see | 08:48 |
| scorp007 | well, the tri-artefacts were present on aqsis without SDS (as you saw on the teapots) | 08:49 |
| pgregory | and triangles are handled in a very (necessarily) awkward way in Aqsis, which probably has an error (or three). | 08:49 |
| scorp007 | perhaps, but the change in algorithm has had many useful side-effects (Aqsis included) | 08:50 |
| scorp007 | it is even faster now too, as less faces are traversed | 08:50 |
| scorp007 | and the quality of output is what the users expect | 08:50 |
| scorp007 | they initially thought CC SDS wasn't good enough | 08:50 |
| pgregory | understandably | 08:51 |
| pgregory | triangles are bad for CC, as they introduce 'extraordinary vertices' all over the mesh, which are bad news for CC SDS. | 08:51 |
| scorp007 | ah, no wonder my cube looked 'wierd' as a SDS before | 08:51 |
| scorp007 | then I tried Liquid and theirs was fine. | 08:52 |
| scorp007 | That's when I discovered the difference in exporting | 08:52 |
| scorp007 | hmm.. what's strange is if I just run "cl" on the command line, I get 'unrecognized command', but if I run scons from the same directory, it is magically found! Also note that the first time I run it from a completely clean checkout, it does not find 'cl.exe' until I setup the environment... | 08:54 |
| pgregory | odd, SCons usually uses the registry to find the compiler. | 08:55 |
| scorp007 | hmmm | 08:55 |
| scorp007 | I just don't feel like doing clean checkouts each time I need to change my environment... | 08:55 |
| scorp007 | there must be a way to make it forget... | 08:56 |
| pgregory | scorp007: did you look at the SCons wiki, I find it's usually quite good. | 08:57 |
| * pgregory gets an itch to try CMake again. | 08:57 | |
| scorp007 | nope, will check | 08:57 |
| scorp007 | lol | 08:57 |
| scorp007 | #scons is dead as ever | 09:08 |
| scorp007 | when scons says Checking for C++ library libtiff... (cached) yes -- how do I un-cache it? | 09:10 |
| scorp007 | I tried deleting options.cache to no avail | 09:11 |
| *** Anteru has joined #aqsis | 09:11 | |
| pgregory | delete .sconf_temp | 09:11 |
| scorp007 | I don't have such a file. I have .sconsign.dblite | 09:11 |
| scorp007 | is that what you meant? | 09:12 |
| scorp007 | Hi Anteru | 09:12 |
| pgregory | there should be a folder named .sconf_temp, if you have the latest SCons installed. | 09:12 |
| pgregory | I beleive it's the latest anyway. | 09:12 |
| scorp007 | ah, oops | 09:12 |
| scorp007 | your right | 09:12 |
| scorp007 | But deleting the file helped!! | 09:12 |
| Anteru | Morning scorp007 | 09:13 |
| pgregory | yeah, it would, but it'll also destroy any other changedata it had stored. | 09:13 |
| scorp007 | maybe not, hmm | 09:13 |
| Anteru | nice, I get a message: "scorp007 wants your attention" :) | 09:13 |
| scorp007 | He does? hehe | 09:13 |
| Anteru | scorp007: Problems with Scons and VC8? | 09:13 |
| scorp007 | Anteru, yeah I just built something in 64 bit and scons thinks I want to build aqsis the same | 09:14 |
| scorp007 | I'm trying to make it forget | 09:14 |
| scorp007 | and say "cl.exe not found" | 09:14 |
| scorp007 | right now it magically knows where cl.exe is | 09:14 |
| Anteru | how did you setup SCons for 64bit building? | 09:14 |
| scorp007 | I didn't | 09:14 |
| scorp007 | I built something else in 64 bit | 09:14 |
| Anteru | ^ you should open the Visual Studio command line for the target platform | 09:14 |
| scorp007 | I did that, now scons seems to remember it | 09:15 |
| Anteru | then, depending on the cli you have choosen, scons will use the cl in the path | 09:15 |
| scorp007 | As in, it knows where cl is even when it's *not* in my path | 09:15 |
| scorp007 | [17:51] <scorp007> hmm.. what's strange is if I just run "cl" on the command line, I get 'unrecognized command', but if I run scons from the same directory, it is magically found! Also note that the first time I run it from a completely clean checkout, it does not find 'cl.exe' until I setup the environment... | 09:15 |
| Anteru | hmm | 09:16 |
| Anteru | To be on the safe side, try to run from the vc command line | 09:16 |
| Anteru | then you can invoke cl directly | 09:16 |
| scorp007 | Erm? | 09:16 |
| scorp007 | You mean the VC command prompt? | 09:16 |
| Anteru | yeah, heck, no idea how it is called in English :) | 09:17 |
| Anteru | Setting environment for using Microsoft Visual Studio 2005 x64 tools. | 09:17 |
| Anteru | That one ^ | 09:17 |
| scorp007 | Tried that | 09:17 |
| scorp007 | I get errors like: conftest_0.obj : error LNK2001: unresolved external symbol __security_check_cookie | 09:17 |
| scorp007 | which is a dead givaway that its trying 64bit mode | 09:17 |
| Anteru | let me try locally | 09:17 |
| Anteru | not that something is really broken | 09:17 |
| scorp007 | no, it's not broken, its on my end | 09:17 |
| scorp007 | that function is defined in a 64bit library | 09:18 |
| Anteru | do you have an options.cache file around? is there some VC path in it? | 09:18 |
| scorp007 | no and no | 09:18 |
| scorp007 | I deleted it many times | 09:18 |
| Anteru | Did you try from the vc command prompt?` | 09:19 |
| scorp007 | the thing is, on a clean checkout it does not find cl.exe which is correct | 09:19 |
| scorp007 | yes, tried that | 09:19 |
| Anteru | and that's also borked? | 09:19 |
| Anteru | Did you change the default search paths via the IDE? | 09:19 |
| scorp007 | yes, same linker erro | 09:19 |
| scorp007 | hmm | 09:19 |
| scorp007 | hold on | 09:19 |
| scorp007 | you could be on to something | 09:19 |
| Anteru | I hope so :) | 09:20 |
| scorp007 | Aha! | 09:20 |
| scorp007 | its set in the IDE | 09:20 |
| scorp007 | hmmm | 09:21 |
| Anteru | xD my start menu looks funny, VS first, VS x64 command prompt second, VS x86 third ... | 09:21 |
| scorp007 | I have a feeling that fixed it | 09:22 |
| scorp007 | (building now) | 09:22 |
| Anteru | there's only one way to know ;) | 09:22 |
| scorp007 | I am 98% sure because when I un-cached the library tests, it failed with the same linker errors | 09:23 |
| scorp007 | now it got past that stage | 09:23 |
| scorp007 | so now I have learned how to de-cache-ify it :) | 09:23 |
| Anteru | building rev 1175 now | 09:24 |
| scorp007 | me too | 09:24 |
| Anteru | (incremental) | 09:24 |
| scorp007 | ah ok | 09:24 |
| scorp007 | you'll beat me then, I cleaned it a few times | 09:24 |
| scorp007 | BTW, Paul, I noticed some shadervm commits, did you address the shader issues? | 09:25 |
| pgregory | scorp007: nope, haven't touched it. | 09:26 |
| scorp007 | oh ok | 09:26 |
| scorp007 | I was hoping to compile the shaders with aqsl and test | 09:26 |
| scorp007 | btw, I may have a bug report for you, which I'll confirm once I build the new version | 09:26 |
| pgregory | sorry, no time at the moment, you'll have to modify the source if you want to test with Aqsis for now. | 09:26 |
| pgregory | the source to your shader that is. | 09:27 |
| scorp007 | is it a big change? | 09:27 |
| scorp007 | I can wait though | 09:27 |
| scorp007 | its not too much of an issue, as I support at least 3 renderers already | 09:27 |
| pgregory | you'll need to split the mix(..., color) into three mix(..., float) calls. | 09:27 |
| Anteru | ^ the link-time code generation takes like a few minutes for aqsis.dll ... | 09:27 |
| scorp007 | oh, I see | 09:28 |
| Anteru | scons: done building targets. | 09:28 |
| scorp007 | scons: done building targets. | 09:29 |
| scorp007 | you just beat me :P | 09:29 |
| Anteru | yeah, well, works here | 09:30 |
| scorp007 | yep, crash confirmed | 09:36 |
| scorp007 | bug: http://sourceforge.net/tracker/index.php?func=detail&aid=1746338&group_id=25264&atid=383970 | 09:39 |
| *** render has joined #aqsis | 10:02 | |
| tcolgate | mornin' all | 10:14 |
| pgregory | hi tcolgate | 10:14 |
| *** pgregory sets mode: +vvv render Anteru AlexK | 10:14 | |
| scorp007 | hin tcolgate | 10:18 |
| scorp007 | hi* | 10:18 |
| *** tcolgate has quit IRC | 10:19 | |
| *** tcolgate has joined #aqsis | 10:20 | |
| *** tcolgate has joined #aqsis | 10:23 | |
| tcolgate | bloodey client! | 10:23 |
| tcolgate | pgregory: I saw the non-copyable sockets commit, seems like a good idea. | 10:24 |
| pgregory | tcolgate: yeah, I was a little worried about duplicating sockets, and I didn't like the idea of not closing a socket during the destructor, so this seemed like the most sensibe solution. | 10:25 |
| *** mafm has joined #aqsis | 10:26 | |
| pgregory | hi mafm | 10:27 |
| mafm | hi | 10:27 |
| *** pgregory sets mode: +vv tcolgate mafm | 10:27 | |
| tcolgate | pgregory: yes, seem like the right approach. You can dup() the FDs for sockets but the behaviiour probably isn't what people would expect. | 10:29 |
| tcolgate | pgregory: Was that the cause of the posix bug you were seeing? | 10:29 |
| pgregory | so | 10:29 |
| pgregory | no | 10:29 |
| tcolgate | No luck on that yet? | 10:29 |
| pgregory | tcolgate: strangely, it works in debug at the moment, I'll rebuild later as release and see if it works there too, if so, I've no idea what it was. | 10:30 |
| tcolgate | hmm, that doesn't sound healthy, but hey-ho | 10:32 |
| pgregory | I made a lot of changes over the weekend on Windows, I wouldn't be surprised to see the problem go away. | 10:32 |
| Anteru | bye | 10:53 |
| *** Anteru has quit IRC | 10:53 | |
| tcolgate | pgregory: just doing a rebuild of the newfb stuff now. | 11:40 |
| *** Joron has joined #Aqsis | 12:24 | |
| *** Joron has quit IRC | 12:36 | |
| pgregory | tcolgate: works here now, no idea why or how, but it's working. | 13:19 |
| pgregory | tcolgate: the only thing I changed that I think could have had in impact was properly initialising the 'total' variable in CqSocket::recvData | 13:19 |
| pgregory | anyway, it's properly saving TIFF files in different formats now, 8bit, floating point tested, 16/32 bits per element not yet tested. | 13:20 |
| tcolgate | pgregory: builds and runs fine here too. | 13:32 |
| pgregory | tcolgate: tested 16bit output, that works fine, but 32bit doesn't but not the fault of piqsl | 13:32 |
| pgregory | it seems that when I do... | 13:32 |
| tcolgate | You've not done the name change yet have you? | 13:33 |
| pgregory | Display "file.tif" "eqshibit" "Cs" "quantize" [0 4294967295 0 4294967295] | 13:33 |
| pgregory | the '4294967295' values are read as 2.14748e+09 | 13:34 |
| pgregory | which suggests the use of a signed instead of an unsigned value somewhere. | 13:34 |
| pgregory | gottit | 13:48 |
| pgregory | the problem is, integer values in RIB are read into an 'int', and as I specified the value in the RIB without a decimal, it was identified as integer by the scanner. | 13:51 |
| pgregory | question is, should integer values be read into an unsigned or signed int? | 13:51 |
| scorp007 | BTW, can piqsl be bound as the default framebuffer in a config file so that when we Display "framebuffer" we get piqsl? | 13:54 |
| pgregory | scorp007: you can modify your aqsisrc to do that if you wish. | 13:55 |
| pgregory | wow, for a change, the answer is in the spec... | 13:57 |
| pgregory | "Numbers include signed integers and reals. An integer consists of an optional sign (`+', `-') followed by one or more decimal digits. The number is interpreted as a signed decimal integer." | 13:57 |
| scorp007 | pgregory, good to hear (re: aqsisrc). | 14:00 |
| pgregory | scorp007: I don't want to make that the default, as eqshibit relies on more stuff than the simple 'display' framebuffer. | 14:00 |
| scorp007 | is the raytracing api standardised? | 14:00 |
| scorp007 | ok, just curious | 14:00 |
| pgregory | scorp007: you mean is RT in RenderMan standardised? | 14:01 |
| scorp007 | yes | 14:01 |
| scorp007 | pixie works differently to 3dl and prman | 14:01 |
| pgregory | in what way? | 14:01 |
| scorp007 | well, it doesn't support the same Attribute "shade" ... Attribute "visibility" "integer transmission" stuff as 3dl or prman | 14:02 |
| scorp007 | and while 3dl supports pixie's way of doing it, its declared deprecated | 14:02 |
| scorp007 | So I implemented the PRman compatible style in my exporter | 14:02 |
| pgregory | hmm, those are attribute based stuff, so they generally aren't defined in the spec. | 14:03 |
| scorp007 | hmm, well they're kind of vital for RT | 14:03 |
| pgregory | renderer implementations often try to stick to the PRMan way. | 14:03 |
| scorp007 | yeah, I left a note on the pixie forums. I stuck to PRman way as 3dl follows it too, and as you say others probably will (or do) follow suit | 14:04 |
| pgregory | basically, anything that is introduced with the "Attribute" or "Option" request is implementation specific, and won't be defined by the spec. | 14:06 |
| scorp007 | oh, I see | 14:06 |
| pgregory | but that information should be clarified by again saying, "most of us try to stick to the PRman way if we can". | 14:07 |
| scorp007 | heh, sure. It would make it easier for exporter writers | 14:07 |
| scorp007 | if we have a pseudo-standard | 14:07 |
| scorp007 | do you guys have any plans to move to renderman Studio, as it's *apparently* the successor to RAT? | 14:08 |
| pgregory | scorp007: we're investigating it. | 14:10 |
| scorp007 | ok | 14:10 |
| scorp007 | what's funny is, the new RfM got a feature called "Motion samples", which is essentially the amount of motion segments to evaluate. In this digital-tutor video showcasing it, the narrator was like "this feature is so amazing, it's worth the upgrade alone". I was pretty surprised RfM 1 didn't have it... | 14:11 |
| scorp007 | I've been able to do that in my exporter all along, and mine isn't limited to a fixed range from 2-6 like theirs | 14:12 |
| pgregory | RfM 1 was really for the 'basic' stuff. | 14:12 |
| pgregory | scorp007: the 2-6 limit is in PRman, not RfM | 14:12 |
| scorp007 | really? 3DL supports unlimited segment? | 14:12 |
| pgregory | as do we | 14:12 |
| scorp007 | Aqsis? | 14:12 |
| pgregory | yes, that's 'us' | 14:12 |
| scorp007 | that's wierd, I wonder why PRMan doesn;t | 14:13 |
| pgregory | history | 14:13 |
| scorp007 | everything is I guess :) | 14:13 |
| scorp007 | I wonder if they implemented that option for motion blur *other than* transformation. Not evident from the video | 14:14 |
| scorp007 | I kind of see why you call it a 'toy' | 14:14 |
| pgregory | you mean RfM? | 14:16 |
| scorp007 | yeah | 14:16 |
| pgregory | it's ok, if all you want to do is render Maya scenes with RenderMan, but if you really want to maximise the power of RenderMan it's not the right tool. | 14:17 |
| pgregory | I can certainly see a market for it, for small, short projects. | 14:17 |
| scorp007 | perhaps | 14:17 |
| pgregory | where you want to use freelancers who 'know' Maya, but have it rendered on the farm in RenderMan, it works. | 14:17 |
| tcolgate | pgregory: Have you heard anythng about the Rushes Short Film thingy coming up? | 14:18 |
| scorp007 | how could you render it on a farm without RIB export? | 14:18 |
| pgregory | tcolgate: err yes, we do it every year. | 14:18 |
| tcolgate | indeedy, have yougot any inside info, anything particularly worth seeing. | 14:18 |
| pgregory | scorp007: I believe you can use RfM via the Maya command line renderer, could be wrong. | 14:18 |
| scorp007 | oh, you could well be right | 14:19 |
| tcolgate | It was mentioned on a leaflet I picked up at the odeon. | 14:19 |
| pgregory | tcolgate: haven't really been following it much here, not enough time. | 14:19 |
| pgregory | it's all managed by an organiser brought in specially to sort it all out. | 14:19 |
| scorp007 | Another funny thing to note, in another digital tutors video, The tutor was explaining how to use Slim with RfM. Boy he was abusing the hell out of it. He built a simple slim shader, flattened it (which bakes all parameters into a constant shader), and loaded it on a Renderman Shader node in maya. Shortly after, he wants to change a parameter, so he goes back to slim, adjusts it, re-flattens (gets many errors) and re-imports it | 14:21 |
| scorp007 | I think he was unaware of the fact you can interactively tweak shader parameters in maya | 14:21 |
| pgregory | eek | 14:21 |
| scorp007 | I was laughing at this guy, he knows next to nothing about renderman | 14:21 |
| pgregory | scorp007: unfortunately it's not easy/possible to get tweakable shader parameters out of Slim, it tends to bake everything. | 14:21 |
| pgregory | due to the way it works. | 14:22 |
| scorp007 | but it generates rib code doesn't it? | 14:22 |
| pgregory | scorp007: no, it generates RSL. | 14:22 |
| scorp007 | sorry, that's what I meant | 14:22 |
| scorp007 | RSL with parameters? | 14:22 |
| pgregory | yes, but with no externally visible parameters. | 14:22 |
| scorp007 | ah | 14:22 |
| scorp007 | but he was voluntarily baking it | 14:22 |
| scorp007 | for some reason | 14:22 |
| pgregory | you have no choice, otherwise it's a Slim appearance, which is TCL, not RSL. | 14:23 |
| scorp007 | But that's a strange workflow isn't it? It defeats the purpose or shader parameters | 14:23 |
| pgregory | scorp007: yes, but Slim isn't meant to work with RfM. | 14:23 |
| scorp007 | how does RAT handle it? | 14:23 |
| pgregory | it's all integrated, you create your shaders in Slim, the editable parameters are internal to the Slim appearance. At render time, MTOR asks slim to 'prepare' the appearance, which involves baking it out to RSL if any parameters have changes, and compiling it. | 14:24 |
| scorp007 | ah, right | 14:24 |
| pgregory | and you directly apply Slim appearances to the scene, not RSL shaders. | 14:25 |
| scorp007 | well if he can afford RAT, why does he even bother with such a retarded workflow with RfM | 14:25 |
| scorp007 | I see, makes more sense | 14:25 |
| scorp007 | Is it possible to attach a handwritten RSL shader in RAT and configure it parameters like in liquid? | 14:26 |
| pgregory | scorp007: he probably chooses RfM over RAT because RfM can render Maya shading trees. | 14:26 |
| pgregory | scorp007: yes | 14:26 |
| scorp007 | yeah, but the purpose of his video was to showcase how to use Slim, not the maya hypershade | 14:26 |
| pgregory | scorp007: I know that, but he was probably showing that "if you need to, it's possible", while still suggesting that the Maya integration is the strength of RfM. | 14:27 |
| scorp007 | oh, right | 14:27 |
| scorp007 | it still smelled like a lack of knowledge on his end... probably from the 'unexpected' errors he was getting and the way he went about resolving them... | 14:28 |
| scorp007 | anyway, gotta go guys | 14:31 |
| *** scorp007 has quit IRC | 14:31 | |
| *** cgTobi has joined #Aqsis | 15:50 | |
| *** ChanServ sets mode: +o cgTobi | 15:50 | |
| pgregory | hi Tobi | 15:52 |
| pgregory | gotta go, cya all later. | 15:56 |
| *** pgregory has left #aqsis | 15:56 | |
| cgTobi | hi Paul, bye Paul | 15:56 |
| cgTobi | hi everyone else | 15:57 |
| mafm | hi! | 15:59 |
| *** AlexK has quit IRC | 16:16 | |
| *** cgTobi has quit IRC | 16:36 | |
| *** AlexK has joined #aqsis | 17:05 | |
| *** render has quit IRC | 17:35 | |
| *** render has joined #aqsis | 17:35 | |
| *** cgTobi has joined #Aqsis | 18:30 | |
| *** ChanServ sets mode: +o cgTobi | 18:30 | |
| *** cgTobi sets mode: +vv AlexK render | 18:30 | |
| *** Anteru has joined #aqsis | 18:49 | |
| mafm | bye | 19:14 |
| *** mafm has quit IRC | 19:14 | |
| *** Anteru has quit IRC | 19:26 | |
| *** Alex_K has joined #aqsis | 19:27 | |
| *** Alex_K has quit IRC | 19:44 | |
| *** AlexK has quit IRC | 19:44 | |
| *** Anteru has joined #aqsis | 20:23 | |
| cgTobi | evening all | 20:28 |
| *** Anteru has quit IRC | 21:48 | |
| *** render has quit IRC | 23:34 | |
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!
