Pages: 1 [2]
  Print  
Author Topic: [WIP] Collada (.dae) 3d Animated Model Loader  (Read 372 times)
Offline (Male) Goombert
Reply #15 Posted on: September 16, 2017, 04:26:04 PM

Contributor
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 2988

View Profile
Yes, the multi-textured terrain I started:
http://enigma-dev.org/forums/index.php?topic=1495.0

Look at TheExDeus's though, his is probably more correct than mine. What I am working on will be related to improving the shaders approach in ENIGMA, so I must focus on that.
Logged
Welcome to ENIGMO, the game engine built by fucking aliens.

Offline (Unknown gender) Solitudinal
Reply #16 Posted on: October 02, 2017, 12:25:32 AM
Member
Joined: Aug 2017
Posts: 16

View Profile
Another update (attn Goombert?):
It's been a while, so I figured I'd check in so you guys know that I'm still hard at work on this.

Static code status:
In case you've missed it, I've made a few changes to the static model code, making it quite a bit leaner.

Animation status:
After endless debugging, I've finished porting the animation code over to C++, and it finally works fantastic. I did break down and start using GLM, and I have a pretty heavy dependency on it right now, because it just made the matrix math that I need so much easier. The end result is about 850 lines of code or 25kb (source, not compiled), plus the shader (50 lines), plus pugixml (375kb source), plus GLM (ehhh...), plus another 200 lines for spinning up my own main/glfw window/glew calls/camera (stuff which ENIGMA normally handles, so that wouldn't be ported over).
I did write GLSL1 shaders for it, and it works great, so that's excellent. Now I'm half waiting on Goombert to share the code for his multi-textured terrain example (the dropbox link is 404) and/or whatever he's secretly doing with shaders -- and half figuring it out myself (which would probably include hacking it a bit myself)

Next:
Porting my code to ENIGMA. This involves figuring out how ENIGMA handles shaders and maybe forcing it to handle how *I* want to use shaders (or hopefully not). Then I'd probably have to replace all my dependencies on GLM with enigma's matrix math, because GLM is massive (2mb) and I don't think ENIGMA wants to add that library just to make model animation a little easier.


Here's a few good notes for users at the current time:
* Multiple models are supported, of course. One model (animated, static, or both) per file. Just construct a new collada model for each one, and point it to the file.
* Static and Animated models will both be supported, with a simple boolean switch in the constructor to determine how to read it in (so exclusively static models don't have to have animation data), and animated models can be read in as animated and still render their static/base model version by simply using a shader that ignores the animation data (in theory, the Fixed Function Pipeline (FFP) should suffice).
* Relatively simple API lets you construct a model with one call, get how long the animation is, set the animation frame (increment each step to animate), and render. There may be a couple other calls to set up the shader, and don't forget to set up the texture, too.
* A single model can be rendered as many times as you'd like in as many different frames (or same frames) as you'd like. In my test code, I've got two guys running and two guys standing, going around in a circle like a merry-go-round.
* No error checking at this time keeps things fast. If anything is missing, it will be omitted, which could easily cascade down to your model not rendering, but the rest of your game should still be playable.
* In order to keep the code small, we make a few assumptions about how the model is constructed and behaves, so a lot of the fancy Collada features will not be present, like materials, special interpolation methods, Collada lights (you have to program your own lights in ENIGMA, you know that), and so on. Refer to the java example model for what features you can use, or feel free to hack in anything I missed.


Hopefully next time you hear from me (may take a while again), I'll have some animation code that you can stick in ENIGMA and use!
If anybody wants to see my current independent (working) code, let me know and I'll consider sharing it, but again keep in mind that it has dependencies on GLFW, GLEW, and GLM, which took me a while to figure out how to set up.
Also, if anybody wants to help, either in this or in the game that I'm working on (no, it's not a 3d MMORPG), that'd be super awesome. Let me know and we can figure out what parts you can work on and/or what parts need done. But I'm assuming most of you guys are probably busy working on your own things right now, so that's fine, I'll just keep chugging away at this :)
Logged
Offline (Unknown gender) Solitudinal
Reply #17 Posted on: October 07, 2017, 01:57:43 PM
Member
Joined: Aug 2017
Posts: 16

View Profile
Just another quick update.

GLM:
I've successfully ditched GLM and replaced it with enigma::Matrix4 and such for the Collada. That actually went smoother than expected, so... thanks?

GL1 / GL3 / shaders:
It's come to my attention that generating my VAO/VBOs currently uses calls to glVertexAttribPointer (generic attributes), which requires GL2.0+. In GL1.1, we used to use fixed attributes glVertexPointer/glNormalPointer/glTexCoordPointer/glColorPointer. I use generic attributes to communicate each vertex's meshed Joints (and its Weights) to the shader. This takes me back to the decision point I was making before, where I either store/render animations CPU-side (as we used to do in GL1.1), or ditch GL1.1 and render them in the shader via calls to glVertexAttribPointer.
Unless someone can suggest some way to salvage GL1.1 support, I'm forced to ditch OpenGL1 and port my code into OpenGL3.

Non-animated code (OP):
The code I shared in the first post, for the base (non-animated) model is fully compatible with GL1.1 (OpenGL1), as it does not depend on VBOs or generic attributes. Feel free to continue using it, and I will continue to support it, but due to the above note, I have no intention of ever adding animation to it. If you want animation, you'll want to switch to OpenGL3. If you're just using it for static models, you can stick to OpenGL1.


Edit: Looking at enigma's GL3 code, you guys didn't make it easy on me. Enigma's Meshes don't support generic attributes either, so I'll probably just bypass Mesh.
« Last Edit: October 07, 2017, 04:41:25 PM by Solitudinal » Logged
Offline (Male) Goombert
Reply #18 Posted on: October 08, 2017, 12:23:45 AM

Contributor
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 2988

View Profile
Sorry for not getting back to you quicker on this. I just have so much going on, but the past week we've spent working really hard to get continuous integration working:
https://github.com/enigma-dev/enigma-dev#enigma--

This is going to be so much better for ENIGMA because it tests all graphics systems (OpenGL & Direct3D) and Windows and Linux as well as all extensions and such in a huge build matrix. Every pull request must pass the CI tests now before they get merged. Anyway, this should mean the graphics systems will break less in the future. It's already done, no more work to do on that, the CI services are running right now.

I and the others who worked on the GL3 system are also aware of the limitations you've mentioned. I was hoping to redo all of this soon and delete a ton of duplicate code from the graphics systems with these new improvements. Bypassing the model struct for now should be absolutely fine but hopefully I can get the vertex buffers actually done in all of the systems soon and remake the model class on top of that.
Logged
Welcome to ENIGMO, the game engine built by fucking aliens.

Offline (Unknown gender) Solitudinal
Reply #19 Posted on: October 08, 2017, 04:10:14 PM
Member
Joined: Aug 2017
Posts: 16

View Profile
Awesome, thanks Goombert. Any luck digging up a copy of that multitextured terrain example?

I'll keep an eye open for changes to the graphics system and try to keep my code current with them, but if you could poke this topic (or the forums in general) when you do revisit and update the model/mesh class, that'd really help me know to re-integrate my code with it.

In the meantime, I'll keep chugging away.
Logged
Offline (Male) hpg678
Reply #20 Posted on: October 09, 2017, 01:25:11 AM

Member
Location: Barbados
Joined: Mar 2017
Posts: 105

View Profile Email
 (Y) (Y)

Keep up the good work guys!
Logged
Hugar
Offline (Male) time-killer-games
Reply #21 Posted on: October 11, 2017, 02:07:42 AM

Member
Location: Virginia Beach
Joined: Jan 2013
Posts: 1061

View Profile WWW Email
I think we should let's get naked.
Logged
Offline (Male) Josh @ Dreamland
Reply #22 Posted on: October 22, 2017, 03:02:40 PM

Prince of all Goldfish
Developer
Location: Ohio, United States
Joined: Feb 2008
Posts: 2933

View Profile Email
If I had time to explore the 3D modeling space in ENIGMA, I would focus on adding support for AssImp in general. I think Collada is a big step in that direction, though, so this is an awesome change. Have you considered putting this code in a pull request? Movement in the 3D space here remains slow.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Unknown gender) Solitudinal
Reply #23 Posted on: Today at 12:22:17 AM
Member
Joined: Aug 2017
Posts: 16

View Profile
I'd looked at AssImp, but the library is massive, so I passed it by. The zip is 30+ MB. I don't know how that would pan out with the rest of ENIGMA.
As far as a pull request goes, I don't actually have a github account, but once the code gets large enough (and stable enough) to warrant it, I'll consider it.
Slow dev or otherwise, I'm happy; with just a little tweaking and some customer support, you have the features I need for my game programming needs.
Logged
Pages: 1 [2]
  Print