BlenderNet supports different types of Nodes: Official Nodes which are provided and maintained by the staff at BlenderNet and Contributed Nodes which are provided by other members. In order to use the Official Nodes to their full potential you will need to purchase what we call Credits. These Credits are used as a type of currency for BlenderNet and are only used when your task is rendered by an Official Node. If you do not have any credits then your task will be rendered using Contributed Nodes and there is no cost.

The pricing scheme is still under development but the above should give you a good overview of how pricing will work with the BlenderNet service.

But your service is a cooperative rendering service where you can join your computers to the grid

for help yours and others projects calculation or is a traditionnal renderfarm services where you to rent\buy

computer power from a big renderfarm on your side ?

You will not be able to submit a project for rendering until we open the service to the public. BlenderNet is currently in the late alpha stage and is very close to being complete for a public demonstration. Once we have more dedicated resources for rendering we will be launching another public test. Subscribe to our news feed to be notified when the public test will occur. In the meantime please feel free to ask any questions you may have.

Just want to know if your service is alway be supported or is dead.

Because it's seem to be a really cool service but i don't see any sign

of life until august 2009 , date of the last news. And no application is

available to download for install it on my computer. I trying to submit a

test too and it's seem to not working.

thanks and hoping you keep working on this great project !

The entire 2.49 Identifier Index can be found here:

http://www.blender.org/documen.....index.html

I whipped up a quick script and tested it out, and it's working   Save the following script as border.py:

import Blender
from Blender import Scene
from Blender.Scene import Render

scn = Scene.GetCurrent()
context = scn.getRenderingContext()
context.enableBorderRender(1)
context.setBorder(0.1, 0.4, 0.2, 0.6)

Then execute Blender from the command-line by typing:

./blender -b ~/Desktop/bordertest.blend -P ~/Desktop/border.py -f 1

http://www.blender.org/documen.....rderRender

We could even modify the node to use user-submitted settings (with limitations of course) to determine how many nodes can render the image.  We might even be able to "auto determine" a suggested setting for optimal performance (based on image size and estimated render time, etc.)

We currently have a huge security hole in our distribution method to contributed nodes.  In a nutshell, any user that creates a contributed node will have full administrator access to other users source project files that are currently rendering on their CPU.  This opens up a lot of legal issues for copyright infringement, and if exploited, could very well ruin our reputation of providing security for customer's data.

Side note: The terms of usage needs updated to represent that we will not be held liable for this type of infringement.

Anyways, given that Blender is open source, we have full access to creating and modifying the applications open/save routines to allow for encryption/decryption of .blend files.  This modified version of Blender could then be distributed along with the BlenderNode for each operating system, providing a much more secure method of distribution.  The .blend files would be encrypted after the user uploads it to our server, and then the encrypted file could be securely transfered to the Render Nodes with much less worry about prying eyes.

There's some things we really have to look more into though ...

First, we have to understand how Blender handles opening .blend files.  I've done some digging through the source code and found:

/source/blender/blendloader/intern/readfile.c

I'm not very versed in programming and reading someone else's code just adds to the fire, but I'm pretty sure we could modify it to work.  Which then leads to the second problem:

Blender is Licensed under GPL.  The only way we will be able to implement this type of functionality without needing to release our encryption methods on demand is to create an external library that Blender can call on.  This will bypass the need for us to release our code (ultimately exposing our own encryption and defeating the purpose).

Thoughts, ideas, comments, and/or suggestions?

The Fix: Install the latest version of XCode, then execute the following command: 

sudo perl -e "use CPAN::FirstTime; CPAN::FirstTime::init();"

This will execute the first boot configuration for CPAN, which will then recognize gcc along with the rest of the tools you'll need.

UI Changes:

• Uploadify needs implemented.  The upload process still needs edited.
• User Login/Logout form.
• Downloading of completed frames.
• Team Invitation system.
• Remove legacy DetailedRender code.
• Consolidation of the JavaScript code and commenting.
• Bugfix for submenu creating all active items after new job upload.
• Bugfix for completed frames dropdown.
• Admin panel functions for database management.
• Ability for the user to change their profile information.
• .Zip upload support with ability to include cache files.
• Functionality for managing pricing tiers.
• Implement jQuery grid for Queue Management (Admin panel).
• Redesign upload process with ajax similar to the node permission management.

Node/Server/Scheduler:

• Modifications to job scheduler to support prioritization and privacy options for the nodes depending on tier level.
• Make blender run in a chroot.
• Create a benchmark .blend file, along with the ability to log benchmark results and rank nodes based on the results.
• Bucket Distribution for Single Frame Renderings.

Service Structure:

• Create comparison charts for competitors with pricing plans.
• Create Tier titles and their respective available options.

These are some of the key areas we covered during testing for the night.

• Registration confirmation emails aren't being sent out.  The forum is possibly overriding it.
• We should look further into cache files.  This is data created by fluid simulations or any other simulation that needs baked into IPO data to render through the command line.
• Administration is being added into the front-end for database management.  GUI's are always a great thing 🙂
• CPU detection needs improved.  We need to make it cross platform as well.

BlenderNet is being designed to manage our own dedicated render nodes as well as your own.  The software is completely cross platform and managed through a web-based interface (at http://www.blendernet.com/members ).  Current functionality supports our dedicated nodes at the moment, but we are working very hard to get our contributed render node management working.  This will allow you to run our software on your render nodes and create an extremely easy to use and setup render cluster.

We are also aiming to provide a commercial rendering solution, so at the moment there are no plans for a free service plan.  We do however plan to make it the most affordable solution for rendering and distributed rendering management.

If you'd like to participate in the public beta, keep your eyes open in the News Section for an official announcement.  Unofficially though, you can join us in #blendernet on irc.freenode.net (port 6667).

Regards,

Brian