Opensource renderengine..support?

Hi,
I saw this on cgchannel.com:
http://renderedrealities.net/portfolio/renderbitch.html
Looks nice. It’s opensource too (free!).
Can anyone perhaps make an export-script for it…just for testing. I’ve tried it myself (never coded in python before :)) but I didn’t get it.
How can i get all vertices in an object?

MiGa

Are you Running Windows because I was trying to write a Makefile for Linux for Render. Bitch catchy name. “What are you doing Honey?” “I am rendering Bitch!” lol that was bad. Never would call Honey that.

Cheers,
Nate Nesler

Oh side note included the GL libraries for the make but the build instructions must not find -lGL and -lGLU enough anyother options I should use for Linking?

Hey, I have just opened up one of the RenderBitch demo scene files. Looks like I should be able to adapt my X-Plane export script to export to RenderBitch!

Seems a pretty simple file format.

I’ll let you know how I get on!

brian

Well, I nearly have an alpha version of the export code working.

(by alpha I mean that it can only export one single object!)

Just a couple of tweaks needed!

watch this space!

brian

I’m watching every single post about that theme.

Stamatis

Yeah, that’s cool!

Hope to test something soon!
Can’t wait to see something rendered

MiGa

Just to let you all know how I am getting on.

I have stumbled into one problem.

The file format for RenderB*tch seems to want a single list of each and every vertex in every object in the scene.

The objects in the scene are then made by referencing the vertex index.

I’m not sure how I would do this, unless you manually join every object together in blender, then export. Then there will be the difficulty of accessing the material of each object, as you would have to be using multiple materials assigned to the new “grouped” object.

Hmmm… It may be possible to construct a list of the vertices, and then work out the correct vertex index by storing the number of vertices of each object in a list.

Then, to calculate the correct vertex indices for the 3rd object, for example, the correct vertex index will be the original vertex index + number of vertices in object 1 + number of vertices in object 2.

Does this sound reasonable? Has anyone else written code to do this that they might share with me?

cheers

brian

If I understand you correctly, you say you need to sort all the verts into one list, all the verts in a scene that is. Correct?

Anyhow, if so, simply add a stop sign or something so you know where one object stops and the next begins. In this example however, things are done wacky, I have no time for explaining it very well in code so the crappy sample will have to do.


list = []

if not len(list):
    i = 0
    list.append('%d' % i)
    i += 1

for v in mesh.verts:
    list.append(v)
    if len(mesh.verts) == v.index:
        list.append('%d' % i)
        i += 1

I’d say using a class object or something that stores the name of the mesh and other info and using that as ‘stop sign’ would be more clever as that would limit things to one list.

Another way of doing it would be storing a list which holds info about the sequences that makes up a list of verts in a scene. Perhaps looking like this:


sequence_list = []

sequence_to_store = len(mesh.verts)

if not len(sequence_list):
    a = [0, sequence_to_store-1]

else:
    b = len(sequence_list)-1
    a = [b, b+sequence_to_store]

Again, sorry for crappy example, this sort of thing should most likely be done with some fancy functions instead ;o)

I’d go for thought #1 though. Would make things easier to parse I believe. And above all, way easier to write, probably faster too. If you do it with a class as a stop sign that is, that stores the name of the object in question, material info perhaps, length of vertex list for reference if that would become necessary. All you could think of. I dunno though, just spouting random nonsense! ;o)

Thats correct. All the vertices which make up the scene are stored in the file as a list. At least, that is how the example files included with RenderBitch are made up.

Anyhow, if so, simply add a stop sign or something so you know where one object stops and the next begins. In this example however, things are done wacky, I have no time for explaining it very well in code so the crappy sample will have to do.

Clever idea. RenderBitch Scene files supports comments, so I suppose
I could use that , for example “#Object Name, number of verts” to seperate the list.

<snip code>

I’d say using a class object or something that stores the name of the mesh and other info and using that as ‘stop sign’ would be more clever as that would limit things to one list.

I’m not sure what a class object is…

Another way of doing it would be storing a list which holds info about the sequences that makes up a list of verts in a scene. Perhaps looking like this:

<snip>
I’d go for thought #1 though. Would make things easier to parse I believe. And above all, way easier to write, probably faster too. If you do it with a class as a stop sign that is, that stores the name of the object in question, material info perhaps, length of vertex list for reference if that would become necessary. All you could think of. I dunno though, just spouting random nonsense! ;o)

Thanks for the suggestions Macke.

regards

brian

Ok.

Clever idea. RenderBitch Scene files supports comments, so I suppose I could use that , for example “#Object Name, number of verts” to seperate the list.

<snip code>

Even simpler then if you don’t need object information. Just do this (warning, heavy pseudo code):

#Imagine the list of verts looks something like (# being seperator):
#[vert1[x,y,z], vert2[x,y,z], vert3[x,y,z], #, vert1[x,y,z], vert2[x,y,z], vert3[x,y,z]]

seperator = '#'

for i in range(len(list)):
    if str(i)[0] == seperator:
        #i is a seperator, next object begins
        dofunkystuff()
    else:
        dootherfunkystuff()

I’m not sure what a class object is…

A class is something that defines a group of properties for a certain object. Or something along the lines of that. I’m terrible with explenations, so it would most likely be best if you read up about classes and objects and inheritance and such in the python documentation.

Thanks for the suggestions Macke.

np.

any news on this?

While I don’t have any news on this one, here is another one that is supposedly going to be released within a month or so:

http://www.mysticgd.com/projects/mystique/mystique.htm

All features look very promising…

Indeed indeed! Looks very promising, looks like it is more developed compared to Renderbitch…

brian

Mystique - yes, I’ve been keeping my eyes open for news on that one.

Andrew