"render only" build

Compiling, libraries, modules, coding guidelines and porting

Moderators: jesterKing, stiv

gabio
Posts: 0
Joined: Thu Jan 15, 2004 6:41 am
Location: Canada - Québec - Sherbrooke
Contact:

Post by gabio »

ideasman wrote: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
This also bring the API side of the idea.
By cuting it out of the main bin, you force yourself to do a nice api, so the internal engine get tothe same level as external. This way you can get other render engine to plug in more easily.
This answer many of the actualy wish: modularity, better support of external render engine. Ho well, this now sound like a blender 3.0 idea...

ideasman
Posts: 0
Joined: Tue Feb 25, 2003 2:37 pm

Post by ideasman »

gabio wrote:
ideasman wrote: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
This also bring the API side of the idea.
By cuting it out of the main bin, you force yourself to do a nice api, so the internal engine get tothe same level as external. This way you can get other render engine to plug in more easily.
This answer many of the actualy wish: modularity, better support of external render engine. Ho well, this now sound like a blender 3.0 idea...
Your totaly right, but is anybody going to spend the time to do this?
Im thinking that a new user could knock up a useable render-only build in under a week mabe another 2 weeks for fine tuning. and in practive it would be usefull and as good as the dll option.

DLL will be more usefull in the long run, but requires a lot more understanding of the render code, and most of those ppl are busy with other stuff right now.

bannerboy
Posts: 0
Joined: Sun Sep 05, 2004 1:18 am

Post by bannerboy »

I thought about totaly wiping python, but as soon as you do that, other more important things start to break, like walkomatic. (correct me if i'm wrong) I beleive it calculates stuff at render time. The reason you have no small binary, is because you still need most of blender in order to render:
Textures
Materials
world
scene
IPO
you get the idea, however, taking out the interface does remove a large chunck of source code.

Post Reply