2.29: radiosity render!

slikdigit · Post by **slikdigit** » Mon Sep 01, 2003 7:41 pm

I did a cvs update and tried to build, but I got the following error from the linker:

source/.libs/libblender_source.al(convertBlenderScene.lo)(.text+0x6c8b): In function `RE_freeRotateBlenderScene':intern/convertBlenderScene.c:2771: undefined reference to `end_radio_render'
source/.libs/libblender_source.al(renderPreAndPost.lo)(.text+0x81): In function `prepareScene':
intern/source/renderPreAndPost.c:92: undefined reference to `do_radio_render'
collect2: ld returned 1 exit status86

any ideas?
oh, building on linux kernel 2.4.20, glibc 2.3.2, gcc 3.2.3 for i686

modron · Post by **modron** » Tue Sep 02, 2003 10:05 am

I would very much like to do animated radiosity,...but I'm not quite clear on what this is. Is it something for tuhopuu, an update patch for blender 2.8a, or a complete version of blender? (VERY cool btw)

Post by **ton** » Tue Sep 02, 2003 12:21 pm

I know I wrote a long text in this posting, but the info people look for is there there:

ton wrote: It just has been committed to the bf-blender tree.

So not tuhopuu!

ton wrote: - the link order for Blender has changed, the libradiosity.a has to be moved after the librender.a (obviously for a new dependency!). Check blender/source/Makefile
- there's a new file: blender/source/radiosity/intern/source/radrender.c

This requires a change in the automake or projectfiles. I mailed instructions for it to the official developers mailing list. I just noticed the MSVC files have been updated, in bf-blender!

slikdigit · Post by **slikdigit** » Tue Sep 02, 2003 3:49 pm

I'll rebuild and play tonight. Thanks Ton!

ton wrote:

- the link order for Blender has ......

I should remember not to skim through the technical notes next time....

soletread · Post by **soletread** » Tue Sep 02, 2003 10:29 pm

Could someone please explain all the excitement in english

What does it mean for us as animators?

------

SirDude · Post by **SirDude** » Tue Sep 02, 2003 10:51 pm

The link order means nothing to animators.
For what improvments and whatnot the changes mean
look at the images and test files in the first post they
should explain it to you.

nempko · Post by **nempko** » Wed Sep 03, 2003 12:18 am

Could someone please build a windows or linux binary with this new feature and post a link to this forum. I unfortunately do not have the time to build it myself, but having the feature would speed up my work greatly.

ilac · Post by **ilac** » Wed Sep 03, 2003 1:49 am

nempko wrote:Could someone please build a windows or linux binary with this new feature and post a link to this forum. I unfortunately do not have the time to build it myself, but having the feature would speed up my work greatly.

Search at Elysiun, there's a windows build for sure. Title of thread says something like Tuhopuu 2 and bf-blender, so don't look away if you see Tuhopuu written too. Both are within the thread!

z3r0_d · Post by **z3r0_d** » Wed Sep 03, 2003 4:21 am

odd:

Code: Select all

make all in source/blender/src
...
buttons.c: In function `radiobuts':
buttons.c:2586: error: parse error before '<<' token
buttons.c:2597: error: parse error before '==' token
buttons.c:2646: error: parse error before '>>' token
buttons.c:2699: error: parse error before '==' token
buttons.c:2734: error: parse error before '>>' token
buttons.c:2746: error: break statement not within loop or switch
buttons.c: At top level:
buttons.c:2748: error: parse error before '}' token
buttons.c: In function `do_blenderbuttons':
buttons.c:7522: warning: implicit declaration of function `do_mballbuts'
/usr/include/bits/stdio.h: At top level:
buttons.c:6620: warning: `avicodec_str' defined but not used
make[3]: *** [/home/temporary/bf-blender/blender/obj/linux-glibc2.3.2-i386/blender/src/buttons.o] Error 1
make[2]: *** [all] Error 1
make[1]: *** [all] Error 1
make: *** [all] Error 1

I gues a cvs update added those lines? one (the last) looks like:

Code: Select all

>>>>>>> 1.36

(for the moment they are remarked, let's see if my compile finishes)

know why this would happen?

and, subdividing would be ideal at render-time (subdivide shoot patch and elements), but I'd imagine the moving levels of detail would be visible.

I was going to look into how UV data could be preserved during radiosity calculation until I saw this thread... (the math for my script isn't coming along well , I have mostly forgotten it this week, and I will not mention details of my new plans (another scipt) until I can verify that I can complete it)

___________ edit _________
it worked (the compile) after I changed the usual

Code: Select all

 SADD = /usr/lib/libGL.so /usr/lib/libGLU.so

from the .a files (libGL.a isn't on my system)

nice stuff

slikdigit · Post by **slikdigit** » Wed Sep 03, 2003 5:40 am

hello all got it working. I'd been using the autoconfed makefiles which didnt' wrok for this- but using the static ones did after making a few simlinks here and there.
Here's a result of my first test (cheat, using two emitters but also one blender spotlight:
http://home.comcast.net/~kurdali/radtest.jpg
its a piece being reworked at the mo, the orignal without radiousity looks like this:
http://home.comcast.net/~kurdali/elements.jpg
that one has about eight lights.
I had to tweak a lot to get the render right, not sure I have any opinions yet (other than its much faster than I had thought) I'll play some more and see.

matt_e · Post by **matt_e** » Wed Sep 03, 2003 5:56 am

How much slower was it to render it using radio vs the original lighting approach? I did some initial tests on a very high-poly model of mine, but didn't have good results and it was really really slow...

Pablosbrain · Post by **Pablosbrain** » Wed Sep 03, 2003 6:20 am

After doing some work with radiosity... (never used it in blender before).. this is very usefull! I still would need those unfinished features before it is really usable in my current project... But holds great promise for better looking animations! I'm very excited about all the developments being done with blender. Once this, reflections and DOF are made easy to use in blender there won't be the huge need for an external renderer.

Unfinished features---
- take into account textured color of faces
- do some smart pre-subdividing.
- unified render

z3r0_d · Post by **z3r0_d** » Wed Sep 03, 2003 6:22 am

it is SLOW (known, radiosity is slow)

the scene I have been playing with really needs a higher hemirez (than the max allows, though it appears the limit is only in buttons.c) but the results do animate better.

Now, I have been reminded of the 16 material max, is a fix planned for 2.29?
(I would test it now, but the file I would test with is not avaliable)
(wait, now it isn't. Shall try...)
it seems not to have that problem, though I am still not fully sure. (someone else confirm if this is true please)

hanzo · Post by **hanzo** » Wed Sep 03, 2003 6:50 am

nobody is showing what this thing can realy do, common guys impress people

OR DO I JUST HAVE A BIG MOUTH...

How much slower was it to render it using radio vs the original lighting approach? I did some initial tests on a very high-poly model of mine, but didn't have good results and it was really really slow...

Dude in my opinion it is very much better and waayy fast I mean it's excellent, although all I've done was play with the test files... I'm haveing some trouble getting it work from new file though..

could somebody right a short 1 paragraph step by step from a new file? plz

PS: TON THANK YOU VERY VERY MUCH FOR THIS EXCELLENT TOOL!!

PS2: slikdigit, heh good one dude!

soletread · Post by **soletread** » Wed Sep 03, 2003 7:32 am

SirDude, wow, thanks for your help. show your face man

Blender.org

2.29: radiosity render!

Re: 2.29: radiosity render!

Please build a binary

Re: Please build a binary