| 20 Dec 2009 09:18:47 pm by TheStorm |
|
Quote |
| elfprince13 wrote: |
| Exams be done. |
Woo, so we should expect a FreeBuild Demo before next semester...  but still good to hear you'll have more time to work on things. |
| 20 Dec 2009 09:45:47 pm by elfprince13 |
|
Quote |
| 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. |
| 21 Dec 2009 12:12:12 pm by KermMartian |
|
Quote |
| 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.  |
| 21 Dec 2009 10:31:27 pm by elfprince13 |
|
Quote |
| ah, excellent, we need to work out some sort of engine-source setup w.r.t. to that |
| 03 Apr 2013 10:03:52 pm by elfprince13 |
What is this madness? |
Quote |
What is this madness?
https://github.com/elfprince13/FreeBuild  |
| 04 Apr 2013 12:57:58 am by elfprince13 |
|
Quote |
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. |
| 04 Apr 2013 01:13:06 am by KermMartian |
|
Quote |
| 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. |
| 04 Apr 2013 01:18:11 am by AHelper |
|
Quote |
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  |
| 04 Apr 2013 01:25:19 am by elfprince13 |
|
Quote |
| 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. |
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 |
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). |
| 04 Apr 2013 10:45:13 am by DShiznit |
|
Quote |
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. |
| 04 Apr 2013 10:54:38 am by elfprince13 |
|
Quote |
| 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. |
| 04 Apr 2013 12:22:26 pm by AHelper |
|
Quote |
| FYI, Blender can convert Quake .map files to Collada as well, in case there is a need for another source of conversion. |
| 05 Apr 2013 12:46:42 am by elfprince13 |
|
Quote |
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.
 |
| 05 Apr 2013 10:00:30 am by DShiznit |
|
Quote |
| 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? |
| 05 Apr 2013 11:10:12 am by elfprince13 |
|
Quote |
If you find a reasonable .map loading library, I'll happily plug it in there.
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. |
| 07 Apr 2013 11:02:23 pm by elfprince13 |
|
Quote |
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. |
| 08 Apr 2013 07:37:52 pm by elfprince13 |
|
Quote |
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. |
| 09 Apr 2013 08:27:11 pm by DShiznit |
|
Quote |
| 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? |
| 10 Apr 2013 11:59:15 am by swivelgames |
|
Quote |
| 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!  |
| 10 Apr 2013 12:02:16 pm by elfprince13 |
|
Quote |
| DShiznit wrote: |
| I heard you mention you might use Bullet for physics? |
That's the plan
| 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++. |
