FYI: I am now admin (technically co-admin it seems) of the SF.net COLLADA-DOM project, and it’s officially been taken out of “Inactive” status.
That’s great, congrats!
In changing the viewer components I’ve opted to work in the SF.net repository directly. I intend to move my changes to the DOM component into that repository so that they will all be together again.
I’ll check them later manually, because I guess Sf only notifies new releases and not sure commits
[QUOTE=recpas;41671]That’s great, congrats!
I’ll check them later manually, because I guess Sf only notifies new releases and not sure commits[/QUOTE]
To be clear, I am just beginning to look at the viewer. I did a major commit today, and a couple follow-ups. For what it’s worth, I received emails for each commit. If you subscribe to the right feed, you can get commit emails.
I posted about the first commit to the Developer forum. I wasn’t sure I was getting notifications for that forum, so I tried to subscribe, but it told me that I was subscribed to everything! Either because I chose to, or because mine is an “admin” account, I don’t know.
Before long I am going to work on a wiki guide. Or one page in the Khronos wiki. And have all of the old COLLADA-DOM pages refer to that guide in bold-print at their tops (their information is all pretty much outdated, but it’s a history of something I guess. I think one page should be plenty.) I think I will do this this week. I also need to update the pregenerated files in the official Download section. I will probably do that tomorrow. Set up is somewhat more involved now though, so I can’t recommend it without a good guide, or some familiarity with the library. (Users must program some interfaces and link to their schemas themself.)
I didn’t get any notifications even though Sf says “You are already subscribed to this project” and I subscribed activity, I’ll try to change my email after reset my passwd. I would prefer Github/Bitbucket/Gitlab… instead of SF, it is very complicated and ugly but it is home of COLLADA-DOM.
Finally I completed convert multi-index array to single index array with duplicating some verts and rendered succesfully also my renderer can now render instance nodes correctly. Now it is time to render lights in COLLADA instead of static lights. I was testing on glfw lib but now I’ve switched to new Cocoa (Mac OS X) app. I’ll make viewer public when finished, hope it will 
Of course there are some cases still need to be handled; <p> is optional which means that there is no indices and primitive (triangle/polys/lines) must be rendered with direct draw instead of indexed draw, multiple <p> element can be located in <polygons> I’ll handle these later
Another good news is that khronos fixed forum search tool and dead links (COLLADA Overview - The Khronos Group Inc…) now we can search in old threads!
That is good news. I was trying to find some of the references from the Sailing the Gulf book that no longer resolve correctly earlier in the year (or last year I guess.)
I’ve uploaded a pregenerated headers package here:
I’ve had some seasonal plumbing problems of late that have me semi distracted from work right now. When the icy weather we were having thawed (and I learned of my burst pipes) I was working on the COLLADA-DOM viewer project. It’s really just a very simple thing I think at base. It will be interesting to see if it has legs going forward.
I must admit that I don’t know much about exotic programming frameworks (or Apple products for that matter.) I keep to the basics because of how those things come and go and are of limited application. Having a good COLLADA ecosystem is very important because it means that documents, etc. can be checked and double checked in lots of different ways under different conditions. Existing software only explores what can be done with COLLADA about 3% or so I think. As you can imagine that can be frustrating if you want to do more with COLLADA! (To be honest there isn’t a whole lot that can be done with just “3%.” It’s functionally useless/worthless as things are.)
Having a good COLLADA ecosystem is very important because it means that documents, etc. can be checked and double checked in lots of different ways under different conditions.
+1, That is right
I hope I can load a test document with new COLLADA-DOM 3/2.5 without version error. Headers are generated but actual source files are still missing. Generating and testing them will take a little time I think
[QUOTE=recpas;41680]+1, That is right
I hope I can load a test document with new COLLADA-DOM 3/2.5 without version error. Headers are generated but actual source files are still missing. Generating and testing them will take a little time I think[/QUOTE]
Version 2.5 is “headers-only” with regard to the procedurally generated files. I may work on a guide today to touch on the finer points. Headers-only is increasingly how C++ packages are implemented/distributed, owing a lot to the modern embrace of templates. When I first started working on it, I made the generator put all of the metadata registration routines in a single CPP file, since that dramatically improved compile times. Now those are functionally inline defined, but the COLLADA_(inline) macro can be manipulated if you need to have them defined in a single translation unit. It must be manually defined. I will have to explain that in a forthcoming guide.
P.S. A few days ago the webmaster here asked me to help moderator the forum(s), because of the spam that is regularly appearing. They also mentioned that they are working on converting the forums over to Discourse (not to be confused with Diqus) which I’d never heard of. EDITED: I only noticed the letter today. Partly because my ISP’s webmail service has been so inundated with spam the last week that I am trying to make a point to find a new email address for myself. Either on my private server, or even I asked if I could get a Khronos mail address. ISPs just don’t take spam seriously and apparently don’t have access to non-commercial spam filters, or are too incompetent. I really wish we could find a technical answer to spam. Even if it involves micro-taxation or something like that. It’s coming to a head I think. It’s such a productivity drain on everybody.
EDITED: BTW. If you think about it, the library can only be headers-only, because it can be used with any schema. It could output translation-units, but the setup of a translation-unit is much more fussy than simply using #include, so that’s undesirable.
Version 2.5 is “headers-only” with regard to the procedurally generated files. I may work on a guide today to touch on the finer points. Headers-only is increasingly how C++ packages are implemented/distributed, owing a lot to the modern embrace of templates. When I first started working on it, I made the generator put all of the metadata registration routines in a single CPP file, since that dramatically improved compile times. Now those are functionally inline defined, but the COLLADA_(inline) macro can be manipulated if you need to have them defined in a single translation unit. It must be manually defined. I will have to explain that in a forthcoming guide.
EDITED: BTW. If you think about it, the library can only be headers-only, because it can be used with any schema. It could output translation-units, but the setup of a translation-unit is much more fussy than simply using #include, so that’s undesirable.
I didn’t check bottom of header, declaring class then define funcs… something like C++ glm repo (g-tunc) I mean sources could be located in separate headers like detail/*.inl files, would be more clear for header only lib. Another word to say is that this will affect the build time for every build (parsing (this part may be cached by compiler or ccache), building, linking everytime)? Of course probably compiler may do more optimizations for header only sources… this will also may take a little extra time
I imported headers to Xcode to test but there is an another issue ColladaDOM.inl this header is missing in headers folder referenced in http_www_collada_org_2005_11_COLLADASchema.h
P.S. A few days ago the webmaster here asked me to help moderator the forum(s), because of the spam that is regularly appearing. They also mentioned that they are working on converting the forums over to Discourse (not to be confused with Diqus) which I’d never heard of.
I hope this will not make forum more complicated and ugly
EDITED: I only noticed the letter today. Partly because my ISP’s webmail service has been so inundated with spam the last week that I am trying to make a point to find a new email address for myself. Either on my private server, or even I asked if I could get a Khronos mail address. ISPs just don’t take spam seriously and apparently don’t have access to non-commercial spam filters, or are too incompetent. I really wish we could find a technical answer to spam. Even if it involves micro-taxation or something like that. It’s coming to a head I think. It’s such a productivity drain on everybody.
Zoho mail is free (and not bad) and ACM/SIGGRAPH give you an email (forwarding only) with spam filtering if you have account e.g. you@acm.org, you@siggraph.org
ColladaDOM.inl includes all of the headers for the core-library. Those are not generated headers. There’s nothing in the generated headers that requires extra parsing. They should be precompiled headers anyway. The only reason there are more than one header file per schema is there are recursive dependencies, and schema are not defined in any order in particular.
Granted, it helps somewhat if you want to browse to the definition of a type (to have a single file to scroll up/down through) but there are already so many files, that there’s no call for there to be more, or twice as many or more.
It shouldn’t even be necessary to include ColladaDOM.inl (it should already have been included) but like the comment says, it’s for things like IntelliSense. It helps them find their legs. You kind of have to use common sense to use the library, but a guide is in order. I wrote up a first draft yesterday, after I spent some time thinking about how to utilize the wiki (COLLADA DOM - COLLADA Public Wiki)