Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.

Can you help with TBG/Freebuild?
Absolutely, love to do some coding
 21%  [ 9 ]
Absolutely, mapping/artwork/interface
 28%  [ 12 ]
No, but I look forward to playing
 45%  [ 19 ]
I have no interest in this
 4%  [ 2 ]
Total Votes : 42

elfprince13 wrote:
Exams be done.

Woo, so we should expect a FreeBuild Demo before next semester... Just Joking but still good to hear you'll have more time to work on things.
honestly, I was hoping to have one done this coming week, but I get screwed over by not being able to do anything with the 9 days beginning with thanksgiving vacation.
elfprince13 wrote:
honestly, I was hoping to have one done this coming week, but I get screwed over by not being able to do anything with the 9 days beginning with thanksgiving vacation.
I look forward to collaborating and coding some rudimentary railroad functionality over the break, if you are so inclined. Smile
ah, excellent, we need to work out some sort of engine-source setup w.r.t. to that
What is this madness?

https://github.com/elfprince13/FreeBuild Evil or Very Mad
Double post, but too bad, because it's kinda cool.
Basically, I'm tired of trying to make other game engines do what I want them to do that they aren't designed for, so I'm writing one myself using C++ and OpenGL, with an embedded Python interpreter for scripting and an HTML/CSS layer for the UI based on libRocket. I've been doing some research on the graphics code I'll need to render LDraw models efficiently, so hopefully it won't take too long to cook up the basic shaders for that.



Code:

//---------------------------------------------

Parsing startup arguments
Initializing graphics drivers... Success!

---------------------------------------------//

Attempting to initiate mainloop.
Importing scripts... Success!
 Contains these submodules: ui
Importing scripts.ui... Success!
 Contains these submodules: main_menu
Successfully imported 'scripts.ui' to begin UI definition.


Tomorrow I'll see about actually getting a UI up and running. Right now the main_menu script is just a placeholder, however libRocket is linked in with a python interface, so it shouldn't be too hard to get something loaded up.
Very ambitious, elfprince; I hope it works out! I am always very happy to hear that this project is still making progress. Also, if my voxelization project works out, I hope we can extend it to not-LEGO. Smile
Seems like you are going down the path that I took for Redintegrate. I never did get used to any of the other engines I tried Sad
KermMartian wrote:
Very ambitious, elfprince; I hope it works out!


KermMartian wrote:
I am always very happy to hear that this project is still making progress. Also, if my voxelization project works out, I hope we can extend it to not-LEGO. Smile


The engine should be optimized around rendering large numbers of low-detail things with a relatively fixed set of shader inputs.

Also keep in mind that while LDraw parts libraries are traditionally and primarily Lego oriented, you can get unofficial K'Nex, Lincoln Log, and Mega Blok parts libraries as well (or anything else, really if you learn the format).

AHelper wrote:
Seems like you are going down the path that I took for Redintegrate. I never did get used to any of the other engines I tried Sad

I'm actually really accustomed to Torque, and Panda looked nice enough when I poked at it a month and a half ago. The problem in both cases was just that the rendering pipeline was not oriented towards what I wanted to do with it, and a rewrite of big systems like that is often harder than doing ground-up implementations.

I know enough about software/API design now that I'm not as concerned about getting myself in a big mess as I would have been even a few years ago (when I was messing around with OpenSceneGraph as a replacement for the TGE rendering engine).
On one hand I'm used to Torque's language and tools and I normally fear change, but on the other, T3D never ran well on my PC to begin with, so I'm rather excited.

Do you think we could get Id/Valve .map support? That would be sweet for those of us that use old school mapping tools like gtk/QuArK/hammer/constructor, which would include all of the mappers Blockland has now abandoned.
DShiznit wrote:
On one hand I'm used to Torque's language and tools and I normally fear change, but on the other, T3D never ran well on my PC to begin with, so I'm rather excited.

Do you think we could get Id/Valve .map support? That would be sweet for those of us that use old school mapping tools like gtk/QuArK/hammer/constructor, which would include all of the mappers Blockland has now abandoned.


I don't know anything about the format, but you should be able to use the BSP plugins for OpenSceneGraph to convert Quake 3 and Valve BSP maps (which are usually what .map gets compiled to, right?) to Collada. And DIF can already be easily converted using T3D 1.1 and the python tools I wrote a month and a half ago. I currently anticipate that I'll support LDraw, and probably at least some Collada, out of the box.

Incidentally, I picked Python over Lua for embedding because I think Python is generally among the most accessible languages to learn.
FYI, Blender can convert Quake .map files to Collada as well, in case there is a need for another source of conversion.
Your console log of the day:

Code:
//---------------------------------------------

Parsing startup arguments
GFX::Driver claiming ownership of ShellSystemInterface
Initializing graphics drivers... Success!

---------------------------------------------//

Attempting to initiate mainloop.
Importing scripts... Success!
 Contains these submodules: ui
Importing scripts.ui... Success!
 Contains these submodules: keybindings, main_menu
Successfully imported 'scripts.ui' to begin UI definition.
Executing configure_ui(800,600)
 Importing standard key bindings... Done
GFX::Driver releasing ownership of ShellSystemInterface


And a picture too, just cause (even though it isn't very interesting). The good stuff is for people who go peek at the code on GitHub.

elfprince13 wrote:
DShiznit wrote:
On one hand I'm used to Torque's language and tools and I normally fear change, but on the other, T3D never ran well on my PC to begin with, so I'm rather excited.

Do you think we could get Id/Valve .map support? That would be sweet for those of us that use old school mapping tools like gtk/QuArK/hammer/constructor, which would include all of the mappers Blockland has now abandoned.


I don't know anything about the format, but you should be able to use the BSP plugins for OpenSceneGraph to convert Quake 3 and Valve BSP maps (which are usually what .map gets compiled to, right?) to Collada. And DIF can already be easily converted using T3D 1.1 and the python tools I wrote a month and a half ago. I currently anticipate that I'll support LDraw, and probably at least some Collada, out of the box.

Incidentally, I picked Python over Lua for embedding because I think Python is generally among the most accessible languages to learn.


Alrighty. I only asked because those used to be common mapping formats(everything from Unreal to Source uses compiled brush maps which are easily ported between those engines) and I was only wondering if there was stock code somewhere you could throw in at the end to tap into that community. But no biggie. If we're doing conversions, I've also seen Valve maps exported as wavefront .obj, which can be converted into anything.

I was gonna learn a few languages over the summer using codecademy. I'll be sure Python is one of them.

EDIT- any idea how animations will be handled? Or are we nowhere near that stage yet?
If you find a reasonable .map loading library, I'll happily plug it in there. Smile

I'll probably support skeletal animations, in some form or another, but I haven't yet planned out what that support will look like. The big thing is that I'll want to design a good API for procedural animations.
Posting spree!

I think I'm about 90% done getting the user action system set up for UI interaction. I won't be surprised if Python's more scope-dependent functionality (as compared to a language like TorqueScript) will force me to do a refactor to eliminate circular dependencies between various modules in the preferences system, but I'm not totally sure.

Other than that, I think I only need to hook up mouse interaction (which will mean a slight refactor of my BoundKey class to push some functionality up an inheritance tree so that BoundKey, BoundMouse, and BoundScroll will all derive from BoundInput).

As far next steps go, after that, I think I'm gonna take a step back from working on UI configuration and get to work on the graphics pipeline and try to test out some instanced rendering to prepare for migrating the LDraw parser over.
Multiple technical posts a day keeps the non-programmers away.


I've decided to go for an "inferred rendering" (click the link if you're interested in graphics-nerdy game engine technology, or just some pretty pictures) solution for the graphics pipeline. Most of the cases where it looks a little ugly are not particularly relevant to our use case (very highly detailed normal maps or lighting, huge numbers of layered transparencies), and it hits the simple setup/good performance sweet-spot between traditional forward rendering and deferred rendering setups.

I'll probably also implement the CHC++ culling algorithm, but I'm waiting to see if I can hijack the spatial hierarchies used by Bullet for physics calculations, or if I'll have to build my own.

[edit]
Also, already up to 2206 lines of code, though about 250 of those are basically just keymappings to convert from glfw keycodes to libRocket keycodes.
I heard you mention you might use Bullet for physics? Also, since you're writing your own engine from scratch, would it be possible to compile for Tegra III Android devices at some point?
DShiznit wrote:
I heard you mention you might use Bullet for physics? Also, since you're writing your own engine from scratch, would it be possible to compile for Tegra III Android devices at some point?
That type of support would be pretty cool down the road. That would give it the potential support for the OUYA console! Very Happy
DShiznit wrote:
I heard you mention you might use Bullet for physics?

That's the plan Smile
DShiznit wrote:
Also, since you're writing your own engine from scratch, would it be possible to compile for Tegra III Android devices at some point?


I have no idea what OpenGL extensions are available on such a device or how much memory it has. If you want to try and get it running though, I'm happy to try and help, but I don't have one to test on or know how cross compiling works. One of the TOB guys has already been messing about with a Windows build, so he can probably help you set up a development environment for the engine in VS, and you can see what's necessary to work with Android in C/C++.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3 ... , 11, 12, 13  Next
» View previous topic :: View next topic  
Page 12 of 13
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement