Quake Model Entities for Radiant

[JDSTONE]

can you look at the rogue ent files i think somethings are missing...

trap shooter should have lava spike and lava ball options i think

the zombie has more spawn flags i think

dose the dragon need a path and not just a path corner?

the laps and candle should have the same lighting as the small torch...

i may be wrong on all of this but this is what i have been thinking after crash testing the ent the last few days. and did you know the mapper can use 2 ent files at the same time! boy did that make a mess for me for a bit!

keep making kick ass quake tools and ill keep testing and braking them. stuff like this keeps quake fun for me so thankyou.

and you need to wright a new tut for me not to understand it been too long!

[MadGypsy]

I don't have any intention of going any further with this. Too much work for zero gain. If you use the standard ent you end up with cubes instead of models anyway. What is the need for a specific texture to be applied to that cube, the color of the cube tells you what you are looking at? Also, textured cube models is still a model that needs to be loaded in radiant, so, you might lessen the amount of data by using a cube instead of the mdl, but regardless it will still need to be loaded and instantiated. Just use the standard ent bro. You aren't going to beat the performance of loading no models at all.

[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

[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.

[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]

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]

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]

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.

[Syluxguy28O3]

interesting work there.

[OMacKnight]

Nice one!

[TR2N]

Thank you, now i understand! Nice!

[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]

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

[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

[JDSTONE]

Kick ass work!