"render only" build

joeedh · Post by **joeedh** » Mon Apr 25, 2005 9:45 am

joeri wrote:So this would need a new blender? It can't be done in the official release?

well, you can tell blender to render from the commandline. . .

I thought you meant an executable that didn't link to X or libGL. theres no way other then a dummy opengl-dummy ghost implementation libs to do that.

joeedh

joeri · Post by **joeri** » Mon Apr 25, 2005 10:57 am

Sorry to be unclear (so what new

)
As I understand the question is if there could be a blender that does not need the X11 libs installed so it could be used on a renderfarm (of Xboxes? , Xboxes are the cheapest PC's around, but any other low setup/install would be nice too)

There are some suggestions made like linking to a phony Xlib. But does this means that's a different blender (pff, my english sucks). Or could the official bf-blender to be made stand alone in cmd/shell mode on all OS ?

I don't know how much demand is for that, probably not alot. It's pretty easy to install Linux on renderfarm machines, and I think X11 is included in most Linux releases?

But I was wondering if it could be done in the bf release or that it would need a fork.

ideasman · Post by **ideasman** » Mon Apr 25, 2005 4:09 pm

joeri wrote:Sorry to be unclear (so what new )
As I understand the question is if there could be a blender that does not need the X11 libs installed so it could be used on a renderfarm (of Xboxes? , Xboxes are the cheapest PC's around, but any other low setup/install would be nice too)

There are some suggestions made like linking to a phony Xlib. But does this means that's a different blender (pff, my english sucks). Or could the official bf-blender to be made stand alone in cmd/shell mode on all OS ?

I don't know how much demand is for that, probably not alot. It's pretty easy to install Linux on renderfarm machines, and I think X11 is included in most Linux releases?

But I was wondering if it could be done in the bf release or that it would need a fork.

Weather a fork is required or not is a design decision, though I think if a fork was required- its probbably not worth maintaining 2 sets of code.

As I understand it- Dummy openGL/Ghost libs would just need to be compiled and blender_render would link to these. Will probably be so small seeing as they do nothing that a static lib would be do-able without much exe bloat.

Also blender dosent have big X11 ties? It compiles on OSX and Win32. and used to compile on BeOS. ghost will be the issue.

bannerboy · Post by **bannerboy** » Mon Apr 25, 2005 8:51 pm

from the little bit of digging arround I've done with the blender source code, the render engine is a speperate cpp file, so you could take quite a lot of the old code, and build a command-line interface to it. It would be a little bit of a project, bute defanintly within the range of possability.

joeedh · Post by **joeedh** » Mon Apr 25, 2005 11:20 pm

bannerboy wrote:from the little bit of digging arround I've done with the blender source code, the render engine is a speperate cpp file, so you could take quite a lot of the old code, and build a command-line interface to it. It would be a little bit of a project, bute defanintly within the range of possability.

its not really all that seperate, and its not C++. although maybe with some work. .. who knows. . .

joeedh

joeri · Post by **joeri** » Tue Apr 26, 2005 9:07 am

ideasman wrote:..., though I think if a fork was required- its probbably not worth maintaining 2 sets of code.

That's what I was thinking.

ideasman · Post by **ideasman** » Tue Apr 26, 2005 1:18 pm

Take the blender player exe, a seperate exe that plays games. obviously its possible to split out some of blenders functionality into a seperate binary.

Probably need an understanding of linking and an idea of the structure of blenders code, these sort of things are more hack work, adding if-defs etc.
If your realy keen, go ahrad, probably do some research then put it to the BF-Commiters as how you intend to go about it. - you dont have to have general support, but youll realy want this to be in BF-Blender, so might be good, also get some advice from other developers.

It would be nice to have a blender renderer that would work with only basic libs. then you could keep support for currently unsupported Os's, BeOS, SkyOs, hobby OS's could easerly port the renderer and add it to there list of supported apps, not like this is the aim, but it wouldent hurt

.

Render binary would be small, I have got a full blender distro to 3 meg bzip2, so Im guessing the renderer would be less then a meg compressed.

Mabe sombody could impliment the render deamon and get it to launch the render only binary, as a seperate project of course but would make the small render binary more attractive, mabe we could have a render node distro, under a meg and supports many OS's.

- Cam

joeedh · Post by **joeedh** » Wed Apr 27, 2005 4:41 am

ideasman wrote:Take the blender player exe, a seperate exe that plays games. obviously its possible to split out some of blenders functionality into a seperate binary.

actually, the gameengine code is extreamly indenpendant of the rest of Blender. unfortunately, the render code is not.

joeedh

bannerboy · Post by **bannerboy** » Fri Apr 29, 2005 10:04 pm

We should probubly think about this, not as what needs to be kept, but what can be removed. If you think about it, the only things that you will be able to remove are the game engine, which can already be removed, and the interface. Everything else: materials, textures, world, scene, action strips, IPO, etc. needs to stay, because much of it is calculated at render time.
The YafRay converter can also be removed, but that's nominal.

ideasman · Post by **ideasman** » Sun May 01, 2005 8:12 am

bannerboy wrote:We should probubly think about this, not as what needs to be kept, but what can be removed. If you think about it, the only things that you will be able to remove are the game engine, which can already be removed, and the interface. Everything else: materials, textures, world, scene, action strips, IPO, etc. needs to stay, because much of it is calculated at render time.
The YafRay converter can also be removed, but that's nominal.

Exactly sombody can add ifdefs and keep it up until all extra stuff is removed, but this is somthing that can be done over time.

Also- removing the need for OpenGL/X11/Win32 libs is not necessarily the no1 issue. - Having a small binary that only renders is usefull even if it does rely on GUI libs. if the libs are not being called, sombody can then go on to remove linking in the build config.
- Cam

bannerboy · Post by **bannerboy** » Tue May 03, 2005 3:08 pm

but it's impossible to make a "small binary" blender is verry small as it is, and you can make a small binary by turning off the gameeingine. I don't think it would be all that much of a problem to remove the interface, but I don't have enough c to do it.

ideasman · Post by **ideasman** » Wed May 04, 2005 12:21 am

bannerboy wrote:but it's impossible to make a "small binary" blender is verry small as it is, and you can make a small binary by turning off the gameeingine. I don't think it would be all that much of a problem to remove the interface, but I don't have enough c to do it.

Have a go, doing this sort of stuff is not necessarly as haed as you think.

1) work out how to do IFDEF's
2) Work out how to set up an option in a Makefile and scons.
3) Remove a fairly large tool - Mesh Bevel for eg. using ifdefs.
4) Compile and test.

Repeat-

Blender binaries arnt that small.

mine is abt 6 meg? w/o game engine- 3meg using UPX to compress and make a runtime binary. I would expect a blender render only build would be under a meg, but thats only a guess.
- Cam

gabio · Post by **gabio** » Wed May 04, 2005 4:50 am

My understanding of the code right now would lead me to think it this way:
Put all the render engine in a library (dll), which blender can use directly to render and preview material. and this way there could also be a front end binary like render.exe that also link to the render engine in the library. the advantage of this is:
1 -do a only render bin,
2 -Give a nice external tools to render in renderfarm for example. A network manager can be easily coded in this frontend bin, you can do server and client bin, still linkin to the same library.
Well hope this sound interesting.

bannerboy · Post by **bannerboy** » Wed May 04, 2005 4:50 am

I haden't thought about stripping out tools, that would make te build smaller and lighter. I may yet play with it. It's just C, and not C++ so I think I can find my way arround the source code a little better. I'll play with the ifdefs. You could probubly strip out a reasonable ammount:
Boolian Opts
Mesh editing
Subdivide
etc.

I'll play with it.

ideasman · Post by **ideasman** » Wed May 04, 2005 5:03 am

The DLL sugestion is good but probably involves more work then simply removing stuff for a seperate build.

Sombody misght say im totally wrong with this one- bus since the UI is a fairly large aspect of Blender, a way of removing it would be to. IFDEF out the Button/Toggle/Sliders in the sourse. Then just keep addressing each compile error as it appiers, IFDEFFING out every block that calls a UI object. You might need to do this carefully since some logic code is wrapped up in UI stuff, but it cant be much since blender -b for background rendering works well.

Another thing to remove is Python support. this could breaka litttle compatibility since blender in background mode now supports switches for running python scripts. But just make that somthing the rendering build will not do.

You can start conservitivly, but there is a lot you can remove.

- Good luck
-Cam