osl-dev@lists.aswf.io

Re: Build errors

Larry Gritz <larry...@...>

#49

Aha, you must be a prior OpenImageIO user.  You need to 'svn update'
and recompile your OIIO -- this code in OSL requires a recent change
to the ParamValueList helper class that's part of OIIO.

At this moment, the required OIIO change is only in the OIIO trunk, it
hasn't migrated to the 0.7 release branch.  Let me know if this is a
problem, and I'll merge it right away.

    -- lg

Show quoted text

On Jan 12, 4:51 am, Adrien Herubel <he...@...> wrote:
Hi,

I encountered several minor build errors both on release and debug. I
corrected a few (I'll release a patch if you're interrested) but there
is one i can't explain :
src/liboslexec/opmessage.cpp:71: error: ‘class ParamValueList’ has no
member named ‘grow’

I didn't find any declaration of the class/struct/typedef of
ParamValueList

I used :
g++ (SUSE Linux) 4.4.1 [gcc-4_4-branch revision 150839]

Got it working I think?

Jon Macey <jma...@...>

#50

Building on Mac OS X (Darwin)

seems to work and run but when I try most of the tests it seems to
fail with a bus error

For example (geomath) edit run.py to work with my local paths

geomath]$./run.py
test.osl:0: warning: Unable to find "/usr/shaders"
sh: line 1: 31148 Bus error               testshade -g 2 2 test >>
out.txt
FAIL

however out.txt

Compiled test.osl -> test.oso
   hypot (3, 4) = 5
   hypot (3, 4, 5) = 7.07107
   reflect (0.447214 -0.894427 0, 0 1 0) =  0.447214 0.894427 0
   reflect (0.447214 -0.894427 0, -1 0 0) =  -0.447214 -0.894427 0
 testing total-internal reflection:
   refract (0.707107 -0.707107 0, 0 1 0, 1.42) =  0 0 0
   frensel:  Kr= 1  Kt = 0  R = 0.707107 0.707107 0  T = 0 0 0
 testing regular refraction:
   refract (-0.436436 -0.218218 -0.872872, 0.267261 0.534522 0.801784,
0.862069) =  -0.415346 -0.266336 -0.869801
   --> verify refract():  1/1.16 = sin(18.0549)/sin(21.0705) =>
0.862069 ?= 0.862068
   fresnel:  Kr= 0.00557254  Kt = 0.739022  R = 0.0623479 0.779349
0.623479  T = -0.415346 -0.266336 -0.869801
   --> verify fresnel():  1/1.16 = sin(18.0549)/sin(21.0705) =>
0.862069 ?= 0.862068
 Varying:
   hypot (0, 0) = 0
   hypot (1, 0) = 1
   hypot (0, 1) = 1
   hypot (1, 1) = 1.41421
   hypot (0, 0, 0) = 0
   hypot (1, 0, 1) = 1.41421
   hypot (0, 1, 1) = 1.41421
   hypot (1, 1, 2) = 2.44949
   reflect (0 -1 0, 0 1 0) =  0 1 0
   reflect (0.447214 -0.894427 0, 0 1 0) =  0.447214 0.894427 0
   reflect (0 -1 0, 0.707107 0.707107 0) =  1 -5.96046e-08 0
   reflect (0.447214 -0.894427 0, 0.707107 0.707107 0) =  0.894427
-0.447214 0
   refract (0.408248 -0.408248 -0.816497, 0 0 1, 0.75188) =  0.306954
-0.306954 -0.900866
   refract (0.801784 -0.267261 -0.534522, 0 0 1, 0.75188) =  0.602845
-0.200948 -0.772138
   refract (0.408248 0.408248 -0.816497, 0 0 1, 0.75188) =  0.306954
0.306954 -0.900866
   refract (0.801784 0.267261 -0.534522, 0 0 1, 0.75188) =  0.602845
0.200948 -0.772138
   --> verify refract():  1/1.33 = sin(25.7279)/sin(35.2644) =>
0.75188 ?= 0.75188
   --> verify refract():  1/1.33 = sin(39.4537)/sin(57.6885) =>
0.75188 ?= 0.75188
   --> verify refract():  1/1.33 = sin(25.7279)/sin(35.2644) =>
0.75188 ?= 0.75188
   --> verify refract():  1/1.33 = sin(39.4537)/sin(57.6885) =>
0.75188 ?= 0.75188
   fresnel() -> Kr= 0.0222824  Kt = 0.552726  R = 0 0 0  T = 0.306954
-0.306954 -0.900866
   fresnel() -> Kr= 0.0505776  Kt = 0.53673  R = 0 0 0  T = 0.602845
-0.200948 -0.772138
   fresnel() -> Kr= 0.0222824  Kt = 0.552726  R = 0 0 0  T = 0.306954
0.306954 -0.900866
   fresnel() -> Kr= 0.0505776  Kt = 0.53673  R = 0 0 0  T = 0.602845
0.200948 -0.772138
   --> verify fresnel():  1/1.33 = sin(25.7279)/sin(35.2644) =>
0.75188 ?= 0.75188
   --> verify fresnel():  1/1.33 = sin(39.4537)/sin(57.6885) =>
0.75188 ?= 0.75188
   --> verify fresnel():  1/1.33 = sin(25.7279)/sin(35.2644) =>
0.75188 ?= 0.75188
   --> verify fresnel():  1/1.33 = sin(39.4537)/sin(57.6885) =>
0.75188 ?= 0.75188

which is the same as the ref

Also had to do a couple of hacks in the oiio ivgl.cpp file to cast the
std::max and std::clamp functions to get it all to compile

I will play with the rest of the tests and see what happens

Cheers

Jon

Re: Got it working I think?

Jon Macey <jma...@...>

#51

I've just run it in gdb and got the following

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000001
0x0016a07d in OSL::pvt::ShadingContext::execute ()
(gdb) up
#1  0x00009608 in main ()


not familiar with the source yet so will investigate more

Show quoted text

On Jan 12, 7:17 pm, Jon Macey <j...@...> wrote:
Building on Mac OS X (Darwin)

seems to work and run but when I try most of the tests it seems to
fail with a bus error

For example (geomath) edit run.py to work with my local paths

geomath]$./run.py
test.osl:0: warning: Unable to find "/usr/shaders"
sh: line 1: 31148 Bus error               testshade -g 2 2 test >>
out.txt
FAIL

however out.txt

Compiled test.osl -> test.oso
   hypot (3, 4) = 5
   hypot (3, 4, 5) = 7.07107
   reflect (0.447214 -0.894427 0, 0 1 0) =  0.447214 0.894427 0
   reflect (0.447214 -0.894427 0, -1 0 0) =  -0.447214 -0.894427 0
 testing total-internal reflection:
   refract (0.707107 -0.707107 0, 0 1 0, 1.42) =  0 0 0
   frensel:  Kr= 1  Kt = 0  R = 0.707107 0.707107 0  T = 0 0 0
 testing regular refraction:
   refract (-0.436436 -0.218218 -0.872872, 0.267261 0.534522 0.801784,
0.862069) =  -0.415346 -0.266336 -0.869801
   --> verify refract():  1/1.16 = sin(18.0549)/sin(21.0705) =>
0.862069 ?= 0.862068
   fresnel:  Kr= 0.00557254  Kt = 0.739022  R = 0.0623479 0.779349
0.623479  T = -0.415346 -0.266336 -0.869801
   --> verify fresnel():  1/1.16 = sin(18.0549)/sin(21.0705) =>
0.862069 ?= 0.862068
 Varying:
   hypot (0, 0) = 0
   hypot (1, 0) = 1
   hypot (0, 1) = 1
   hypot (1, 1) = 1.41421
   hypot (0, 0, 0) = 0
   hypot (1, 0, 1) = 1.41421
   hypot (0, 1, 1) = 1.41421
   hypot (1, 1, 2) = 2.44949
   reflect (0 -1 0, 0 1 0) =  0 1 0
   reflect (0.447214 -0.894427 0, 0 1 0) =  0.447214 0.894427 0
   reflect (0 -1 0, 0.707107 0.707107 0) =  1 -5.96046e-08 0
   reflect (0.447214 -0.894427 0, 0.707107 0.707107 0) =  0.894427
-0.447214 0
   refract (0.408248 -0.408248 -0.816497, 0 0 1, 0.75188) =  0.306954
-0.306954 -0.900866
   refract (0.801784 -0.267261 -0.534522, 0 0 1, 0.75188) =  0.602845
-0.200948 -0.772138
   refract (0.408248 0.408248 -0.816497, 0 0 1, 0.75188) =  0.306954
0.306954 -0.900866
   refract (0.801784 0.267261 -0.534522, 0 0 1, 0.75188) =  0.602845
0.200948 -0.772138
   --> verify refract():  1/1.33 = sin(25.7279)/sin(35.2644) =>
0.75188 ?= 0.75188
   --> verify refract():  1/1.33 = sin(39.4537)/sin(57.6885) =>
0.75188 ?= 0.75188
   --> verify refract():  1/1.33 = sin(25.7279)/sin(35.2644) =>
0.75188 ?= 0.75188
   --> verify refract():  1/1.33 = sin(39.4537)/sin(57.6885) =>
0.75188 ?= 0.75188
   fresnel() -> Kr= 0.0222824  Kt = 0.552726  R = 0 0 0  T = 0.306954
-0.306954 -0.900866
   fresnel() -> Kr= 0.0505776  Kt = 0.53673  R = 0 0 0  T = 0.602845
-0.200948 -0.772138
   fresnel() -> Kr= 0.0222824  Kt = 0.552726  R = 0 0 0  T = 0.306954
0.306954 -0.900866
   fresnel() -> Kr= 0.0505776  Kt = 0.53673  R = 0 0 0  T = 0.602845
0.200948 -0.772138
   --> verify fresnel():  1/1.33 = sin(25.7279)/sin(35.2644) =>
0.75188 ?= 0.75188
   --> verify fresnel():  1/1.33 = sin(39.4537)/sin(57.6885) =>
0.75188 ?= 0.75188
   --> verify fresnel():  1/1.33 = sin(25.7279)/sin(35.2644) =>
0.75188 ?= 0.75188
   --> verify fresnel():  1/1.33 = sin(39.4537)/sin(57.6885) =>
0.75188 ?= 0.75188

which is the same as the ref

Also had to do a couple of hacks in the oiio ivgl.cpp file to cast the
std::max and std::clamp functions to get it all to compile

I will play with the rest of the tests and see what happens

Cheers

Jon

Re: Got it working I think?

Larry Gritz <l...@...>

#52

The "run.py" script takes arguments (which are passed when the testsuite is run).  You want:

	cd testsuite/YOURTEST
	./run.py . ../../build/ARCH

(ARCH in your case is "macosx")

Does that help?  If not, can you do a 'make debug' and see if you can figure out the line where it's crashing?

	-- lg


On Jan 12, 2010, at 11:17 AM, Jon Macey wrote:

Building on Mac OS X (Darwin)

seems to work and run but when I try most of the tests it seems to
fail with a bus error

For example (geomath) edit run.py to work with my local paths

geomath]$./run.py
test.osl:0: warning: Unable to find "/usr/shaders"
sh: line 1: 31148 Bus error               testshade -g 2 2 test >>
out.txt
FAIL

however out.txt

Compiled test.osl -> test.oso
  hypot (3, 4) = 5
  hypot (3, 4, 5) = 7.07107
  reflect (0.447214 -0.894427 0, 0 1 0) =  0.447214 0.894427 0
  reflect (0.447214 -0.894427 0, -1 0 0) =  -0.447214 -0.894427 0
testing total-internal reflection:
  refract (0.707107 -0.707107 0, 0 1 0, 1.42) =  0 0 0
  frensel:  Kr= 1  Kt = 0  R = 0.707107 0.707107 0  T = 0 0 0
testing regular refraction:
  refract (-0.436436 -0.218218 -0.872872, 0.267261 0.534522 0.801784,
0.862069) =  -0.415346 -0.266336 -0.869801
  --> verify refract():  1/1.16 = sin(18.0549)/sin(21.0705) =>
0.862069 ?= 0.862068
  fresnel:  Kr= 0.00557254  Kt = 0.739022  R = 0.0623479 0.779349
0.623479  T = -0.415346 -0.266336 -0.869801
  --> verify fresnel():  1/1.16 = sin(18.0549)/sin(21.0705) =>
0.862069 ?= 0.862068
Varying:
  hypot (0, 0) = 0
  hypot (1, 0) = 1
  hypot (0, 1) = 1
  hypot (1, 1) = 1.41421
  hypot (0, 0, 0) = 0
  hypot (1, 0, 1) = 1.41421
  hypot (0, 1, 1) = 1.41421
  hypot (1, 1, 2) = 2.44949
  reflect (0 -1 0, 0 1 0) =  0 1 0
  reflect (0.447214 -0.894427 0, 0 1 0) =  0.447214 0.894427 0
  reflect (0 -1 0, 0.707107 0.707107 0) =  1 -5.96046e-08 0
  reflect (0.447214 -0.894427 0, 0.707107 0.707107 0) =  0.894427
-0.447214 0
  refract (0.408248 -0.408248 -0.816497, 0 0 1, 0.75188) =  0.306954
-0.306954 -0.900866
  refract (0.801784 -0.267261 -0.534522, 0 0 1, 0.75188) =  0.602845
-0.200948 -0.772138
  refract (0.408248 0.408248 -0.816497, 0 0 1, 0.75188) =  0.306954
0.306954 -0.900866
  refract (0.801784 0.267261 -0.534522, 0 0 1, 0.75188) =  0.602845
0.200948 -0.772138
  --> verify refract():  1/1.33 = sin(25.7279)/sin(35.2644) =>
0.75188 ?= 0.75188
  --> verify refract():  1/1.33 = sin(39.4537)/sin(57.6885) =>
0.75188 ?= 0.75188
  --> verify refract():  1/1.33 = sin(25.7279)/sin(35.2644) =>
0.75188 ?= 0.75188
  --> verify refract():  1/1.33 = sin(39.4537)/sin(57.6885) =>
0.75188 ?= 0.75188
  fresnel() -> Kr= 0.0222824  Kt = 0.552726  R = 0 0 0  T = 0.306954
-0.306954 -0.900866
  fresnel() -> Kr= 0.0505776  Kt = 0.53673  R = 0 0 0  T = 0.602845
-0.200948 -0.772138
  fresnel() -> Kr= 0.0222824  Kt = 0.552726  R = 0 0 0  T = 0.306954
0.306954 -0.900866
  fresnel() -> Kr= 0.0505776  Kt = 0.53673  R = 0 0 0  T = 0.602845
0.200948 -0.772138
  --> verify fresnel():  1/1.33 = sin(25.7279)/sin(35.2644) =>
0.75188 ?= 0.75188
  --> verify fresnel():  1/1.33 = sin(39.4537)/sin(57.6885) =>
0.75188 ?= 0.75188
  --> verify fresnel():  1/1.33 = sin(25.7279)/sin(35.2644) =>
0.75188 ?= 0.75188
  --> verify fresnel():  1/1.33 = sin(39.4537)/sin(57.6885) =>
0.75188 ?= 0.75188

which is the same as the ref

Also had to do a couple of hacks in the oiio ivgl.cpp file to cast the
std::max and std::clamp functions to get it all to compile

I will play with the rest of the tests and see what happens

Cheers

Jon
-- 
You received this message because you are subscribed to the Google Groups "OSL Developers" group.
To post to this group, send email to osl...@....
To unsubscribe from this group, send email to osl...@....
For more options, visit this group at http://groups.google.com/group/osl-dev?hl=en.

--
Larry Gritz
l...@...

Re: Got it working I think?

Jon Macey <jma...@...>

#53

still getting the fails,

If I do a make debug I get loads of boost Undefined symbols: errors
(for example)

Linking CXX shared library liboslexec.dylib
Undefined symbols:
  "boost::detail::get_tss_data(void const*)", referenced from:
 
boost::thread_specific_ptr<OSL::pvt::ShadingSystemImpl::PerThreadInfo>::get
() const  in shadingsys.cpp.o
  "boost::detail::set_tss_data(void const*,
boost::shared_ptr<boost::detail::tss_cleanup_function>, void*, bool)",
referenced from:
 
boost::thread_specific_ptr<OSL::pvt::ShadingSystemImpl::PerThreadInfo>::reset
(OSL::pvt::ShadingSystemImpl::PerThreadInfo*)in shadingsys.cpp.o
ld: symbol(s) not found

and

Linking CXX shared library liboslcomp.dylib
Undefined symbols:
  "boost::filesystem::detail::status_api(std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&,
boost::system::error_code&)", referenced from:
 
boost::enable_if<boost::filesystem::is_basic_path<boost::filesystem::basic_path<std::basic_string<char,
std::char_traits<char>, std::allocator<char> >,
boost::filesystem::path_traits> >, bool>::type
boost::filesystem::exists<boost::filesystem::basic_path<std::basic_string<char,
std::char_traits<char>, std::allocator<char> >,
boost::filesystem::path_traits> >
(boost::filesystem::basic_path<std::basic_string<char,
std::char_traits<char>, std::allocator<char> >,
boost::filesystem::path_traits> const&)in oslcomp.cpp.o
ld: symbol(s) not found

Will need to check my boost install and get back to you (tomorrow now)
as the non debug version compile fine

Cheers

Jon

Show quoted text

On Jan 12, 7:35 pm, Larry Gritz <l...@...> wrote:
The "run.py" script takes arguments (which are passed when the testsuite is run).  You want:

        cd testsuite/YOURTEST
        ./run.py . ../../build/ARCH

(ARCH in your case is "macosx")

Does that help?  If not, can you do a 'make debug' and see if you can figure out the line where it's crashing?

        -- lg

On Jan 12, 2010, at 11:17 AM, Jon Macey wrote:



Building on Mac OS X (Darwin)seems to work and run but when I try most of the tests it seems to
fail with a bus errorFor example (geomath) edit run.py to work with my local pathsgeomath]$./run.py
test.osl:0: warning: Unable to find "/usr/shaders"
sh: line 1: 31148 Bus error               testshade -g 2 2 test >>
out.txt
FAILhowever out.txtCompiled test.osl -> test.oso
  hypot (3, 4) = 5
  hypot (3, 4, 5) = 7.07107
  reflect (0.447214 -0.894427 0, 0 1 0) =  0.447214 0.894427 0
  reflect (0.447214 -0.894427 0, -1 0 0) =  -0.447214 -0.894427 0
testing total-internal reflection:
  refract (0.707107 -0.707107 0, 0 1 0, 1.42) =  0 0 0
  frensel:  Kr= 1  Kt = 0  R = 0.707107 0.707107 0  T = 0 0 0
testing regular refraction:
  refract (-0.436436 -0.218218 -0.872872, 0.267261 0.534522 0.801784,
0.862069) =  -0.415346 -0.266336 -0.869801
  --> verify refract():  1/1.16 = sin(18.0549)/sin(21.0705) =>
0.862069 ?= 0.862068
  fresnel:  Kr= 0.00557254  Kt = 0.739022  R = 0.0623479 0.779349
0.623479  T = -0.415346 -0.266336 -0.869801
  --> verify fresnel():  1/1.16 = sin(18.0549)/sin(21.0705) =>
0.862069 ?= 0.862068
Varying:
  hypot (0, 0) = 0
  hypot (1, 0) = 1
  hypot (0, 1) = 1
  hypot (1, 1) = 1.41421
  hypot (0, 0, 0) = 0
  hypot (1, 0, 1) = 1.41421
  hypot (0, 1, 1) = 1.41421
  hypot (1, 1, 2) = 2.44949
  reflect (0 -1 0, 0 1 0) =  0 1 0
  reflect (0.447214 -0.894427 0, 0 1 0) =  0.447214 0.894427 0
  reflect (0 -1 0, 0.707107 0.707107 0) =  1 -5.96046e-08 0
  reflect (0.447214 -0.894427 0, 0.707107 0.707107 0) =  0.894427
-0.447214 0
  refract (0.408248 -0.408248 -0.816497, 0 0 1, 0.75188) =  0.306954
-0.306954 -0.900866
  refract (0.801784 -0.267261 -0.534522, 0 0 1, 0.75188) =  0.602845
-0.200948 -0.772138
  refract (0.408248 0.408248 -0.816497, 0 0 1, 0.75188) =  0.306954
0.306954 -0.900866
  refract (0.801784 0.267261 -0.534522, 0 0 1, 0.75188) =  0.602845
0.200948 -0.772138
  --> verify refract():  1/1.33 = sin(25.7279)/sin(35.2644) =>
0.75188 ?= 0.75188
  --> verify refract():  1/1.33 = sin(39.4537)/sin(57.6885) =>
0.75188 ?= 0.75188
  --> verify refract():  1/1.33 = sin(25.7279)/sin(35.2644) =>
0.75188 ?= 0.75188
  --> verify refract():  1/1.33 = sin(39.4537)/sin(57.6885) =>
0.75188 ?= 0.75188
  fresnel() -> Kr= 0.0222824  Kt = 0.552726  R = 0 0 0  T = 0.306954
-0.306954 -0.900866
  fresnel() -> Kr= 0.0505776  Kt = 0.53673  R = 0 0 0  T = 0.602845
-0.200948 -0.772138
  fresnel() -> Kr= 0.0222824  Kt = 0.552726  R = 0 0 0  T = 0.306954
0.306954 -0.900866
  fresnel() -> Kr= 0.0505776  Kt = 0.53673  R = 0 0 0  T = 0.602845
0.200948 -0.772138
  --> verify fresnel():  1/1.33 = sin(25.7279)/sin(35.2644) =>
0.75188 ?= 0.75188
  --> verify fresnel():  1/1.33 = sin(39.4537)/sin(57.6885) =>
0.75188 ?= 0.75188
  --> verify fresnel():  1/1.33 = sin(25.7279)/sin(35.2644) =>
0.75188 ?= 0.75188
  --> verify fresnel():  1/1.33 = sin(39.4537)/sin(57.6885) =>
0.75188 ?= 0.75188which is the same as the refAlso had to do a couple of hacks in the oiio ivgl.cpp file to cast the
std::max and std::clamp functions to get it all to compileI will play with the rest of the tests and see what happensCheersJon
--
You received this message because you are subscribed to the Google Groups "OSL Developers" group.
To post to this group, send email to osl...@....
To unsubscribe from this group, send email to osl...@....
For more options, visit this group athttp://groups.google.com/group/osl-dev?hl=en.--
Larry Gritz
l...@...

Review: message passing of closures, and bug fixes

Larry Gritz <l...@...>

#54

We're big fans of code reviews BEFORE committing into the trunk, and at SPI used ReviewBoard religiously while developing OSL.  We're still trying to figure out how to do reviews the way we prefer, now that we're on google code; their native tool is set up for post-commit reviews.

So here's our first try at using codereview.appspot.com, a google web app that lets you make code reviews for local changes that haven't been committed, against a public repository.  Let's see how well it goes.  Apologies if it's clunky until we figure out the logistics.

There will probably be a duplicate email to the group, since I specified osl...@... as a CC on the review app.

http://codereview.appspot.com/186135

--
Larry Gritz
l...@...

Bug fix with compound initializers (issue189060)

larry...@...

#56

Reviewers: ,

Message:
Review at http://codereview.appspot.com/189060

Description:
Bug introduced with r507 when I overhauled compound initializers in
ASTvariable_declaration.  Forgot one place where they needed to be
handled.


Please review this at http://codereview.appspot.com/189060

Affected files:
  M     src/liboslcomp/codegen.cpp
  M     src/liboslcomp/oslcomp.cpp


Index: src/liboslcomp/codegen.cpp
===================================================================
--- src/liboslcomp/codegen.cpp	(revision 517)
+++ src/liboslcomp/codegen.cpp	(working copy)
@@ -515,7 +515,14 @@

     if (init() && sym->fieldid() < 0) {
         // Normal vars with initializers -- generate them
-        for (ASTNode::ref i = init();  i;  i = i->next()) {
+
+        // If it's a compound initializer, look at the individual pieces
+        ref init = this->init();
+        if (init->nodetype() == compound_initializer_node) {
+            init = ((ASTcompound_initializer *)init.get())->initlist();
+        }
+
+        for (ASTNode::ref i = init;  i;  i = i->next()) {
             completed &= param_one_default_literal (sym, i.get(), out);
         }
     } else {
Index: src/liboslcomp/oslcomp.cpp
===================================================================
--- src/liboslcomp/oslcomp.cpp	(revision 517)
+++ src/liboslcomp/oslcomp.cpp	(working copy)
@@ -601,7 +601,7 @@
     }

     if (m_ircode.size() == 0)   // If no code, still need a code marker
-        oso ("code main\n");
+        oso ("code ___main___\n");

     oso ("\tend\n");

Re: Bug fix with compound initializers (issue189060)

cku...@...

#57

LGTM

http://codereview.appspot.com/189060

Review: bug fix with compound initializers

Larry Gritz <l...@...>

#55

http://codereview.appspot.com/189060

Sorry, I can't quite seem to get the review comments to automatically get sent to this list.  Do we care?  Would you guys like to see every review-related email, or just the initial "there is a review for Foo at http://blah"?

--
Larry Gritz
l...@...

Question about BSDFClosure functions

brecht <brechtv...@...>

#58

Hi,

First, let me say thanks for releasing this as open source, it's
looking very impressive. I'm working on the shading system in Blender
and was looking into how this design compares to what I'm planning and
how I could make my implementation compatible such that OSL could be
plugged in at a later time.

I have a question that I couldn't find an answer to in the
documentation or source code. The BSDFClosure has eval_reflect,
eval_transmit and sample functions. Some rendering engines have an
additional function to compute the average reflected or transmitted
color independent of the incoming light direction, by the integrating
the bsdf over the incoming light direction without any lights. In PBRT
for example this function is called rho.

There are a number of uses for this:
* Compute surface albedo, i.e. "unshaded color", to output as a pass
for example.
* Compute surface opacity (by doing this for transmission), useful as
a pass for compositing, rasterization with alpha or transparent
shadows.
* Importance sampling by picking one of two blended bsdf's
proportional to this.

It would be possible to compute this value by doing the integration
each time, calling the sample function a number of times, but this is
not as efficient as it could be. Or these values could be manually
provided by the shader writer. Maybe there is another way to do this
that I'm missing, or perhaps it was left out intentionally, or not
implemented yet, ..?

Thanks,
Brecht.

Re: Question about BSDFClosure functions

Alex Conty <aco...@...>

#59

Apparently I can't post here from my work address, so resending. Sorry
if somebody gets a duplicate.

Hi Brecht, I'm Alejandro Conty (jandro in the old blender days), we
met
several times at the Blender conference. Nice hearing from you about
this.


I have a question that I couldn't find an answer to in the
documentation or source code. The BSDFClosure has eval_reflect,
eval_transmit and sample functions. Some rendering engines have an
additional function to compute the average reflected or transmitted
color independent of the incoming light direction, by the integrating
the bsdf over the incoming light direction without any lights. In PBRT
for example this function is called rho.

I understand the main use for this is importance sampling. I'm afraid
I'm not allowed to say how we do things here at imageworks, but there
are other ways to do importance sampling. That function would make
things easier, of course, the problem is that not all BSDF's can be
easily integrated. The expensive method is not an option, it would be
overkill. So you need an analytical solution which is not always
available.

There is also a practical issue too. We have this sample function
that
has to return a normalized PDF and so. It turns out that people find
it
very hard to implement it in some cases. Even when the PDF doesn't
have
to match the BSDF exactly. So adding that extra function could be
asking
for too much. But the discussion is open and you are wellcome in.

Let's see what the other guys think about this ...

Alex

Re: Question about BSDFClosure functions

Larry Gritz <l...@...>

#60

On Jan 14, 2010, at 9:31 AM, Alex Conty wrote:

Apparently I can't post here from my work address, so resending. Sorry
if somebody gets a duplicate.
If it's just a case of the message bouncing because it doesn't know you (at work) are a member of the group, try signing up for a second googlegroups membership, using your work address, and check the box that says "web participation only, no email".  That will make it accept emails from you but not send you duplicate emails to both your work mail and your gmail account.

I have to say, one of my main annoyances with google code hosting is that so many things require "google credentials" rather than one's normal home or work email and userid.

--
Larry Gritz
l...@...

Our code development

Larry Gritz <larry...@...>

#61

I hope you all can see from the traffic in the last few days that
Imageworks is not merely planning to occasionally snapshot OSL and
release it, but rather we are committed to developing the whole thing
in public, warts and all.  (This is not just my idea, but indeed is
the explicit directive from management.)

The google code SVN *is* our development trunk, we are trying to do
all our code reviews over this mail list and codereview.appspot.com,
and use the google-hosted bug tickets for our actual issue tracking
(except for cases specific to our in-house renderer or that discuss
unreleased films).

So you'll see everything, be it good, bad, ugly, or irrelevant.  But
you'll also see the steady daily progress, maybe learn something about
our development process, and some of you, I hope, will be inspired to
participate.

    -- lg

Review: fix derivatives of mod()

Larry Gritz <l...@...>

#62

http://codereview.appspot.com/189073

Ugh, still having trouble making it send all review emails to this list automatically.

--
Larry Gritz
l...@...

Issue 48 in openshadinglanguage: texture() should take optional param for missing texture

openshadi...@...

#65

Status: New
Owner: larrygritz
CC: os...@...

New issue 48 by larrygritz: texture() should take optional param for  missing texture
http://code.google.com/p/openshadinglanguage/issues/detail?id=48

Currently, texture() lookups to nonexistent textures are an error (that
propagates up to the renderer).  The shader team has suggested that it
would solve some awkwardness if there was an optional argument to texture,
somewhat similar to "fill", that gives a color value to use for entirely
missing textures (and it is not an error for this to occur).  If the arg is
not supplied, it's an error to ask for texture that is not found.

I can think of a couple ways to do this:

(1) a separate "missing" color that is analogous to "fill" (fill is used
for missing channels in a present texture).  Also a "missingalpha" for the
alpha case?

(2) just a bool that means whether or not a missing texture is an error.
  (2a) just use the fill value when missing?
  (2b) use a global value for missing texture value? (via
shadingsys->attribute)  Do you need a different color on a shader-by-shader
basis?

Opinions?



--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

Re: Issue 48 in openshadinglanguage: texture() should take optional param for missing texture

openshadi...@...

#66

Updates:
	Cc: larrygritz
	Labels: Type-Enhancement Priority-Medium Milestone-20100210

Comment #1 on issue 48 by larrygritz: texture() should take optional param  for missing texture
http://code.google.com/p/openshadinglanguage/issues/detail?id=48

Sample comment (I'm just testing the email)

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

Patch crediting

Blair Zajac <bl...@...>

#63

Now that OSL is open source (congrats!), I recommend using the following guide on crediting patches from non-core developers in log messages:

https://svn.apache.org/repos/asf/subversion/trunk/www/hacking.html#crediting

You can then use the Contribulyzer to analyze commits to see who you would like to promote to full committers:

http://www.red-bean.com/svnproject/contribulyzer/

See this chapter "Teams and Tools" from the "Beautiful Teams: Inspiring and Cautionary Tales from Veteran Team Leaders" book by Karl Fogel, one of the Subversion founders on the tool and the issues it sovles:

http://www.red-bean.com/kfogel/beautiful-teams/bt-chapter-21.html

Regards,
Blair

Re: Issue 48 in openshadinglanguage: texture() should take optional param for missing texture

openshadi...@...

#67

Comment #2 on issue 48 by jonogibbs: texture() should take optional param  for missing texture
http://code.google.com/p/openshadinglanguage/issues/detail?id=48

I would want a separate color per shader, and would not like 2b. And "fill"  is a
float, and I'd not always want the missing color to be greyscale. I would  prefer (1).

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

Re: Issue 48 in openshadinglanguage: texture() should take optional param for missing texture

openshadi...@...

#68

Comment #3 on issue 48 by larrygritz: texture() should take optional param  for missing texture
http://code.google.com/p/openshadinglanguage/issues/detail?id=48

Agreed.  After I posted that, I was convinced from internal discussion that  it needed
to be a shader decision (example: you might want missing color texture to  be a
different "average" than a missing displacement amount).  And yes, I'm  going to make
it a color.


--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

Tickets not in mail list

Larry Gritz <l...@...>

#64

In an effort to keep the mail list free of clutter, I think we're deciding NOT to CC the list on every ticket.  Instead, those of you who want to follow the gory details of every ticket and every checkin should subscribe to the RSS feed for the project, which will have blurbs for every last ticket comment and checkin.

We're still feeling our way around how this should all work.

--
Larry Gritz
l...@...