Quake Model Entities for Radiant

[MadGypsy]

Quake Model Entities for Radiant



This package includes:

1) QME4R.pak - external skins for all non-box-shaped models
2) entities.ent - altered entity definitions for all non-box-shaped models
3) items/ - folder which contains all box-shaped model assets
4) items/items.pak - box-shaped model assets
5) items/entities.ent - altered entity definitions for all models
*) Read_Me.txt - 2 short files that give information on the project and installation (depending on which version [non-box/with box])

Things to note:

1) Box shaped models are included separately because they don't work properly in radiant. They work properly in everything else that can display an .mdl. So, maybe you can fix that (cause we can't).

2) Keys and Sigil will have to be manually changed in the model attribute of the radiant ent to display proper worldtypes. It comes default as base keys and end1 sigil. The skins for the other keys/sigils are already included.

3) Unlike the previous post of this project, all armor types display properly now

4) anything info_*_start related displays the player character

5) flames and torches have too many problems and no real gain to ever be included

Download QME4R

contributors - golden_boy, Gypsy, talisa
project based on a question by Breadman

[golden_boy]

Good job. Thanks!

[JDSTONE]

Kick ass work!

[MadGypsy]

Rogue Model Entities and Game Pack for Radiant



I wrote the whole gamepack for rogue including it's .ent and set it up for model entities in radiant. Light and box-shaped models are not included. Within the gamepack I expanded the amount of texture, model and compression types that radiant will use/recognize (as compared to the standard q1 gamepack)

Download - RME4R.zip

[TR2N]

Sorry, but i don�t understand this. What can it do? What�s this for?

[talisa]

@TR2N
it allows yu to see the monster and item models in GTKradiant in the view-window instead of blocks.

so that while building a map you can see all the enemies and items you place in it and can already see how itll look like with all the monsters present

[TR2N]

Thank you, now i understand! Nice!

[OMacKnight]

Nice one!

[Syluxguy28O3]

interesting work there.

[MadGypsy]

And to add to what Talisa said, the second pack also makes it possible to map for the rogue progs.dat. I knew before I made it that it was too niche' to really be of any use, but I figured I would bang it out anyway as a sort of practice.

Honestly though, I wouldn't even use either of these and I'll tell you why. Its not really that processor friendly. A cube has 12 triangle polys. A model has significantly more and can have significantly more than the first significance.

I guess it boils down to something like this. If you are using this solely because you can see your models in the map while you build it, I would say this is a bad decision. If you take this work and apply its technique to specific models that you want strictly placed, then this makes a lot of sense to use. Then again if you have a fast computer it probably doesn't matter either way. Personally, I do not have a computer that likes 100+ actual models in the map editor.

There is a little bit of an extra gem hidden within the rogue pack. I wrote the rogue.game file to consider more file types than the standard q1 one. In the q1 gamepack only mdl, tga, jpg, wad and pak are considered. My rogue.game considers

mdl md2 md3 obj tga png jpg wad pak pk3

What this actually means is, radiant will recognize and in some cases even look for these file types. This strictly deals with what is displayable and available in Radiant and has no effect on the end game. I could (ex) make other simpler models that are better than a colored cube but less dense than the actual models. Then I could tell radiant to display them in the stead of the real models. I would only see this in radiant. As long as the entity names match the names of the entities in QC, the proper model will be displayed in the actual game.

---------------------

I like this thought and maybe I will make replacement models that are just cubes with representational art for a texture...ie use the shambler skin on all upright sides of the cube and maybe just the head for the top and bottom, then reproduce that concept for each entity.

[MadGypsy]

Meh, I know this isn't very good. Consider it an early example. In the above post I pondered simply reskinning boxes, so poly counts for the radiant display can be lowered vs using the actual models. This posed a problem. Boxes don't work in radiant...or at least nobody that has worked on this has made a working box yet. I have managed to get all sides of a box, except the bottom, to display. This is actually inconsequential because you would never see the bottom anyway (except maybe a flying monster).

Anyway, the below is a rudimentary textured box example of another possibility on how to use radiants in-map model display.



P.S. yes, I drew the texture myself, and yes I know it is sad. My main focus was getting a box to work and coming up with a guideline that could be used by all textures. In other words, if I ever get one box to work, I'll just copy/paste/rename that box to match an alternate texture name... and that texture will be laid out identical to how this one is, just with different graphics.

[MadGypsy]

Hmmm, I just realized a problem with this that I will have to overcome. The registration point in the world for this model would be far too low in contrast to where the actual models registration point should be.

One way to fix this would be to lower the box in blender accordingly for each actual model. This is not ideal at all, though. That would have me making all these different cubes for each model. I need some trial and error. Maybe I can trick radiant in the ent.

edit: or - the cubes could be placed significantly higher than the floor and droptofloor can take care of it.

[MadGypsy]

Finally nailed it! This UV layout and edgeflow produces a perfectly displayed cube in radiant. I'm still gonna have to figure out what to do about it's origin. The bottom X pattern was unavoidable. I actually cut the top X to be consistent. Maybe this could be done with 2 less polys... lemme see



edit: nope. It has to be just like I have it or it gets messed up. That's cool though. 16 polys is better than 408 (the real player model). That's a 96% reduction. Meaning, you could basically use 25 times the amount of models in radiant (par your system). This is relative to which model you are replacing, of course.

@talisa - blender 2.49 was all I used. I didn't use any additional programs. To get the size where I wanted it, I opened radiant and instantiated the model. I then compared it to the grid. It was 8x8x8. I then went back in blender edit view and pressed a,s,4,left click ((select all, scale, 4 times bigger, commit)). That gave me the 32x32x32 that I wanted.

[MadGypsy]

Oh man, this is great! The origin point doesn't seem to matter. I set the cube exactly on the floor, built the project and ran it in DP. The player was perfectly on the floor and the DP console didn't say anything about "unstuck player at...". So, this just works. Basically at this point it is just a texture project. I don't even need blender anymore.

[JDSTONE]

is the reskinning boxes ent file still a work im progress. would like to use it! i wish i could use the mdl ones but i think that's too much for my system...

there is a bunch of replacement models for the bsp format items maybe one of the authors of thows packs could offer up there models in a mdl format to be used for this...

let me know when its good to go so i can be a crash test dummie