Game Development Community

Removing of COLLADA files for publishing possible?

by Tobias B. · in Torque 3D Professional · 07/27/2009 (3:06 am) · 26 replies

Hi,

I have a short question: Imagine one day T3D is finished and people start publishing their games. The COLLADA DAE models are given away with the game and anyone would be able to get, modify and reuse the COLLADA models. Maybe a game publisher would like to avoid that. As far as I got it, T3D just uses the auto-generated DTS models after they have been generated. I tried to remove the DAE-file, but then T3D complains and doesn't show the models.

Could you please comment on this?
Page «Previous 1 2
#1
07/29/2009 (1:34 am)
Hi,

maybe one of the GG folks knows more about this point?
#2
07/29/2009 (1:51 am)
I am pretty sure the point is: that you can remove the collada before product release...it probably just isn't 100% ready yet.
#3
07/29/2009 (7:50 am)
Sounds like a bug - have you posted a bug report for it?
#4
07/29/2009 (8:55 am)
It is still looking for those collada files. It does use teh cached.dts versions, but this is automatic functionality. Yes you can remove the files...but also remove the references to those files, and replace the references with the '.dts' version of the shape.

Not finding a file that doesn't exist is not a bug ;)
#5
07/29/2009 (9:26 am)
Depends on the point of view.
Would consider that the job of the building functionality actually to take the DTS, change reference and leave the collada out
#6
07/29/2009 (10:05 am)
I wouldn't call "allowing file type choices" a bug.
- This allows us to use 'whatever formats we choose to use'& without forcing our content back to another file type.

Besides, find and replace in a text editor like Notepad++ is terribly easy.
find: .dae
replace with: .cached.dts

#7
07/29/2009 (10:20 am)
Marc,
That would destroy the file change notification functionality. If you change/save a DAE file...it will detect that, and automatically re-load the change (also re-creating the DTS).

I think that the functionality you describe would very seriously frustrate many artists ;)
#8
07/29/2009 (10:22 am)
Hmm. I would have thought we would treat shape files just like we do textures. With a texture I can start with a .png and later on switch to using .dds files, all without changing my script (so long as I don't directly reference an extension).

For a shape we would first look for a .dae file. If found, compare against any found cached .dts file and either use it or (re)generate it. Without a .dae file present, load in the .dts file (cached or not).

I've not poked around the shape loading code for a while, but is there any reason we wouldn't want to go this route?

- Dave
#9
07/29/2009 (10:31 am)
Does referencing a non-existent .cached.dts file automatically loads the DAE?
#10
07/29/2009 (1:40 pm)
Would be a nice function to have in the mission editor when you are ready to ship run a scan for and shape.cached.dts fils and if there are any there rename then to shape.dts and then change the references in the mission file. The torque tool's packager already has the functionality to cull the .dae files out.
#11
07/29/2009 (2:07 pm)
@Dave - That sounds like the desired behavior to me.
#12
07/29/2009 (3:54 pm)
IMO, spot on Dave.
#13
07/30/2009 (3:43 am)
Quote:Marc,
That would destroy the file change notification functionality. If you change/save a DAE file...it will detect that, and automatically re-load the change (also re-creating the DTS).

Perhaps I'm stupid, but I don't see how.
I would be seriously frustrated if the editor, after detecting a change, just decides to totally break my packaged product and repackaging it.

Because thats the step I was talking about :)
I don't care about it in the editor etc, as I want it to use the original data there for fast iteration.

But on packaging (which is out of our hands as far as I see unless the decision to make the management tool source accessable too or you expand its functionality to allow us to add build scripts that process our assets before packaging), I don't see any intelligent reason not to behave a "tad smarter" and correct the references as required.
#14
07/30/2009 (5:24 am)
Yeah, what David suggests is how I would expect this to work.
#15
07/30/2009 (7:49 am)
Agreed. That's honestly how the functionality should work if you don't want to ship DAE files with the build.
#16
07/30/2009 (3:46 pm)
I was bored, here you go. The changes are very small, basically delaying a return NULL if there's no DAE until it verifies there is also no DTS.

source\ts\collada\colladaShapeLoader.cpp
TSShape* loadColladaShape(const Torque::Path &path)

~383: Cut this block of code
if(!ro)
   {
      // File doesn't exist, bail.
      return NULL;
   }
   if (ro->mZipArchive)
      objPath.setPath(ro->zipPath);

~420: Paste it below below the next if conditional so your file looks like this:
if(!ro)
   {
      // File doesn't exist, bail.
      return NULL;
   }
   if (ro->mZipArchive)
      objPath.setPath(ro->zipPath);

   // Load the Collada file into memory

~395 : And finally find the conditional that looks like this
if (Platform::compareFileTimes(cachedModifyTime, daeModifyTime) >= 0)
and replace it with this
if ((Platform::compareFileTimes(cachedModifyTime, daeModifyTime) >= 0) || !ro)
#17
07/30/2009 (3:51 pm)
trunkin' this ?
#18
07/30/2009 (4:14 pm)
I appreciate brevity as much as the next guy, but must you comment on forum threads like they're instant messages?

Are you trying to ask if this code will make it in to the trunk code base?
#19
08/08/2009 (5:52 pm)
JustinD getting back in the Torque game! Nice!
#20
08/09/2009 (2:36 pm)
I was actually wondering if you would be polite enough to put it in my car's trunk, inside of a cedar wood trunk, while wearing swimming trunks.

funny aside:
..We're talking about code and game development, is there any other trunk ?

//Edit: I think it would be quite practical to add this(or similar change) to the code trunk.
Page «Previous 1 2