Collision importer/extractor

[thelink2012]

colex - Collision Importer/Extractor

Little Story

I was wandering and wanted to make all kind of models accept embedded collisions, but first I had to make a utility which imports such collision into the clump... Jesus, why do I need to write a rw io library just for that? WOOO, WAIT! I remember seeing THEHERO posting a kind of rw io library, that'll save me a lot of time my hero. Done, should I be a good open source citzen and send my improvements to the original repository? I think so. What do you think?

Changes to the Library

Well, to accomplish my objective I had to add some stuff to the library, which I think will be useful later on too.

• Added a rw::Stream class which allows you to store a entire renderware stream object (dff, txd, whatever). It supports the basic read, write, clear methods.
• Added bool HeaderInfo::findChunk(std::istream &rw, uint32 type, std::streampos max), useful to find a chunk only inside another chunk boundary.
• I also changed the sized typedefs to use cstdint instead.

Possible Issues

• I had trouble compiling from your makefile (must be a problem on my side), but I've changed the makefile to reflect my changes, but I guess you should test it to make sure it's fine.
• I tried to wrote code similar to how you write, however I failed on that when declaring iterators, I had to use auto! I'm sorry if the code is supposed to compile on older C++ versions, feel free to change my iterator declarations.

Licensing?

Eh, I'm not sure what I'm allowed to do with the code in this repository, since there's no license, and usually no license means copyright... So am I allowed to redistribute the colex utility? Really a license on the page would help so nobody needs to ask (Choose it carefully!!!!)

Final Question

I've read this from the README: "Some chunks are not read and thus skipped as of now, though" What does that really mean for me? Will the dff files I add the collision model extension into break because of those not readen chunks? Thanks in advanced. Keep up all your good work.

[quiret]

Looks interesting! The new contribution of your library is the "findChunk" logic that browses a stream chunk directory for a specific stream chunk.

The thing I do not get is why you put pointers to data (dff, col, etc) into a "Stream" class. In my opinion the container that holds those objects (a DFF holds lights, atomics and cameras) should store them itself. I think that is what "aap" has in mind aswell.... a sort of RenderWare plugin system that Criterion invented.

Despite my criticism, thank you for your contribution!

PS: I kinda forked his code aswell, on another repository. Well, if aap has something against that, he can always drop me a message and it's gone. But I think that, in an open source world, contribution from different people is worth gold.

[aap]

I don't have the time right now to look at and merge this, but thanks for the contribution. Pretty cool there some development going on now with the three of us. Notice I added a findChunk() function myself some time ago.

As for the license: I don't really care about all that, so I'm making it public domain.

I will update the README and TODO files later (they're no longer up to date and there is information missing).

Actually I'm planning to rewrite this whole thing to use an RW-style plugin system, fix some of the bugs or ugly code and incorporate your contributions. My current goal is to convert the PS2 map files to PC and I'm still having trouble with the dffs. After I'm done with that I think I will start a clean rewrite.

[thelink2012]

@quiret That's the thing, I needed to read the entire container on memory to perform my operations on it (I could probably do it in another way, but that felt more intuitive for me), and then write back.

@aap Yeah, but the findChunk present doesn't search only in a chunk boundary, i.e. I wanted to search for Extension inside a Clump but it would find it until the end of file (which might contain various clumps).

I was thinking about writing a modern C++ wrapper around the library (RW stuff is too C like!), but since it's going to be rewritten, I guess I should wait for it.

[quiret]

I see. I would suggest to virtualize the meaning of a RenderWare object. When a stream chunk is being read, its header tells you what is is supposed to be. Hence you create a special object which uses the generic "RwObject" class. Then you can create a stream which holds a list of generic "RwObject" containers.

This would imply that RenderWare objects are parsed through a central function, unlike the current implementation.

I suppose that is what you intend, too. Let's wait and see what aap will come up with ;-)

[thelink2012]

btw why is the over bloated windows.h included in renderware.h?

EDIT and news from my embedded collision hack for all kinds of model. Yeah, nope, LODs have to link with the same model as the non-LOD model :(

[aap]

Hey thelink2012, you said you wanted to write a C++ wrapper. I began implementing an RW style plugin system a few days ago but don't really see the great benefits using C++ would have anymore (and since I'm not a big fan of C++ I think I may switch to C). Maybe we can talk about our ideas on how to implement such a thing the best way in an IM? Quiret, do you have any ideas about this? I suggest we meet in an IRC channel for that. I created #rwtools on freenode now.

BTW, the reason I still haven't accepted your pull request is just that I don't want to work on this code base anymore.

[quiret]

Alright. I will be joining this IRC channel regularily.

[quiret]

I really like the idea of a collision exporter and importer! Could you try coding this on the new "librw" codebase? It should be much cleaner since it has a very RW-like Stream system now.

Hope to see ya regularily on the IRC channel too.