Any interest in Vivid2.0 OpenSource?

I'm mainly developing the engine for my game, so I'm not all that concerned about making money off it, but I'm not entirely sure if there are many openGL coders here, or at least many who'ed be interested in taking part?

Ignore the mess of TrinityOS, I'm talking about a clean (Non-modulized, so no mingW bs required atm) build with a few working examples(Including 3ds loader atm), shaders already supported(GLSL) and I'd document each part of the engine and indicate what needs done, etc..

It could be great to have a uber powerful engine coded by a bunch of coders...in fact, I can't see how an engine coded by one guy(me or anyoneelse) can better it!

Any interest at all?

Here's a small example of the engine, incidentally, that creates a cube and loads a jeep. The engine is entirely OOP based.



give or take a typo.

Ooh, yeah you know im interested. Although I might have to change that to something like:

Local Gfx:Display = Display.Create(640,480,32,FullScreen)

'Create the arena for the demo
Local Game:World=new World
Local Cam:Camera=Game.CreateCamera(Gfx)

'Create a cube.
Local Test:Entity = Game.CreateCube()

'Create a material
Local Metal:Material = New Material

'Load and add texture to material, assign material to cube.
Metal.AddTexture( "Metalic.Jpg" )        'Function takes an object and can take a string or a preexisting texture
'Btw, what would happen if i added another? multitexturing? what about bump mapping?
Test.SetMaterial( Metal )

Test.SetPosition(5,0,10) 'you left this stuff out btw

Local Man:Entity = Game.LoadEntity("SwordMan.3ds")
Man.SetPosition(-5,0,10)

'Have the engine decide - vertex arrays only if supported

Repeat
 Display.Cls()
 Cam.Render()
 Display.Flip()
Until Keydown(Key_ESCAPE)

without comments cluttering it up - for me comments confuse the meaning almost:

Local Gfx:Display = Display.Create(640,480,32,FullScreen)

Local Game:World=new World
Local Cam:Camera=Game.CreateCamera(Gfx)

Local Test:Entity = Game.CreateCube()
Local Metal:Material = New Material
Metal.AddTexture( "Metalic.Jpg" )
Test.SetMaterial( Metal )
Test.SetPosition(5,0,10)

Local Man:Entity = Game.LoadEntity("SwordMan.3ds")
Man.SetPosition(-5,0,10)

Repeat
 Display.Cls()
 Cam.Render()
 Display.Flip()
Until Keydown(Key_ESCAPE)

I imagine there will be lots of disagreements on the best way to code the interface, this seems pretty good to me.

Perhaps we should design it and then make it (obviously the stuff youve already made will give a good head start)

I'd be happy to help...

Bot, yeah I know man, sorry for not sending it to you like I promised. Just sorting out a lighting bug before I do.

Three people is probably enough to get things rolling in the kind of direction that will attract more people to the project... I'll probably start doc'ing the engine code tonight and see how it goes.

Few comments on your design suggestions in the meantime bot,


Local Gfx:Display = Display.Create(640,480,32,FullScreen)



The batch renderer object is a sub class of the Visulizer set up. In essence it IS the above, only more flexible because it could be something like a octree, or a combination.
I'm happy to discuss changes in termonolgy though. Visulizer sounds cool but it's not very describtive.


A general 'game' class to simply things like the above seems fine though. Would make things easier to learn and would result in less cluttered engine classes.



wrong quote but screw it. In answer to your question, you can add as many textures as you like, the engine uses gl extensions for multi-texturing. Shadergen generates shaders correctly for multiple textures too.
Bump-mapping is not supported yet, but shaders are in, so the hardest part is generating tangants. That needs to be done first.


Test.SetMaterial( Metal )
Test.SetPosition(5,0,10)


I'd prefer to keep loading in the fileIO class, to leave room for extended classes with multi-threading support. I've already wrote a working threads library for windows, so this will happen for sure on at least one platform.

Repeat
Display.Cls()


Ah, well you can actually do Cam.RenderEntity( Entity) atm without needing a visulizer, but to render all would require a visulizer to be passed to the current camera presently.
We can discuss if this is the best way to go, though, obviously.
Display.Flip()

Fair enough. Yeah, i was kinda set on the idea of using worlds. If its basically the same as a 'BatchRenderer' thats fine. The only functional differences between my 'world' and your 'visualizer' are that with a world you add objects directly to it rather than creating objects and then adding them to it. Also, worlds can have multiple cameras. With your system as I have seen it so far, It would be pretty hard if you wanted to have, say a rear-view mirror cam without moving the main camera around all the time or adding every object to the rear view mirror's renderer.

So, the only things im interested in changing now are possibly the ability to give strings for some of the functions that take handles for textures, entities, etc. Oh, and:

'Set both meshes to use vertex arrays.
Man.SetRenderClass( VertexArray.Create() )
Test.SetRenderClass( VertexArray.Create() )

You could still be able to do this but if you left it out the engine would pick the best method based off the card, the object (animated/not - you could add in the ability to mark that a specific static meshs will be modified every frame).

Game is the world the cube is being added to. I couldnt call it world because thats the name of the type... A way to load and add something to the renderer in one call would be good though.

I would help, but I know nothing.
If you need any busy-work done, though, such as final docs, I can give that a shot.

The problem is, render classes are extended from from the renderbase class. I.e they are plugins. So it's not entirely certified there will be only one vertex array implentation.
So, although it's easy enough to have a default method, there's no real way of determining a 'best' method.


Oh, misread. Well in that case we can't really do that, because visulizers, as above, are engine plugins, and are not integeral. You can remove them from the engine and it'll run. add new ones etc.
Mostly semantics at this point anyway, it's early enough to streamline these aspects in other ways anyway.
--


Pickle, thanks, I'm sure I could do help with anything involving use of the English language :)

if you post it people will be interested, if they aren't well whats wrong with them :P

Code my engine. Didi-mow!

:)

Well, some methods will not be supported by some graphics cards though, and if they are hard coded it will fail. I would have a abstract function in the base type for the methods called something like "Works()" or "Supported()", which determines if this particular method is supported by the graphics card. So, if Supported() returns 0 then it will not use the method, or return an error. So, some are better than others because they actually work :). On top of this many methods are obviously better than others. For instance, vertex buffers>vertex arrays>glBegin(GL_TRIANGLES), as far as speed for static meshes goes. For dynamic meshes vertex arrays are better than vertex buffers, so in order to determine this the user must inform the engine if a static mesh they loaded will change alot - perhaps through a flag.

Maybe a function in each type like Fitness#(Dynamic=0) which returns an arbitrary value, based on what other methods return. For instance, for static meshes, just passing vertices to the card would be 1, vertex arrays 2, vertex buffers 3. Other methods could insert themselves between or around these values. In the beginning, probably on the graphics call, it will decided on the optimal method for static or dynamic meshes. This technique for selection of defaults could of course be applied to other things like how to do dynamic enviornment maps - shader or cube maps.

As for the actual method of doing this, before any user code is run, each type registers itself by calling a registration function with one example of itself created through new. I believe that the engine can take these examples and call the functions mentioned above, and more importantly, create. This allows it to arbitrarily select a plugin.

Yeah, that is possible.

Presently the loader system(Also plugin based) does exactly that. Each loader calls a method in the base loader class to register it's self.(the loader's new method defines the extension that invokes it),
but the renderClasses do not have a registration based system.
But if we did as you suggest then we can do exactly that, let the engine pick one using supports.

Probably want a Specialized flag in there, so it doesn't pick any renderclasses that are for special circumstances.
-

Just one final bug to fix and I'll send it to you, then hopefully put it online to get the ball rolling.

Ok, I fixed the final known bug and have send you it Bot. Let me know if you have any problems.

hey Ant... if this thing is working, or if you want to see what works and what doesn't, on the macintosh side, send it to me, and a list of what you want looked at...

mailto://mikey102@...

--Mike

id be intrested to see it as well i have a couple linux and windows machines I can run it on