Black Obelisk (MD3 model)

Information:
Name: Black Obelisk
Connection: No
Palette: Doom
Summon: BlackObelisk, BlackObeliskNoBase, BlackObeliskFloat
Ambient Sound: No
De-/Activatable: No
Destroyable: No
Special Effects: No
Brightmaps: Yes
Actor modification: No
ACS: No

Credits:
Code: Rifleman
GLDefs: N/A
Sounds: N/A
Textures/Materials: Ola Bjorling/ukiro
Sprites: Rifleman
Sprite Edit: N/A
Idea Base: Not many obelisks in Doom

Description:
This is a model(MD3) of an obelisk, intended purely as a decoration. It uses several black marble textures from OTEX(included) and a brightmap created by me so the inscription glows. Model is low poly so it should fit nicely.

Sprite and model:
        



Download Link:
Here

This is pretty cool.

There's a lot of potential for 3D models in Doom (pushable, destroyable crates, rotating ceiling fans, moving platforms, pipes, railings etc.).

You can clip into the base - you could solve this by spawning an extra overlapping invisible actor with the dimensions of the base.

Thanks I've updated the actor - increased the radius and height of the "inside actor", the blocking is now much improved IMO.

 

The ZIP archive the submission is included in should include 2 files, one being a copy of the Info template and description called Info.txt, and the other of the Credits template, called Credits.txt (Obviously).

As for the submission itself, the collision box of the actor is too small, it's about half as tall as the model, so objects can completely clip through the upper portion of the model, such as projectiles, players, flying NPCs etc. There is also slight clipping at the base of the obelisk still. Both of those could be fixed by setting the actors' radius to 80 and the height to 490. However, since the base of the obelisk is significantly thicker than the obelisk, I'd be best to follow Captain Toenails' suggestion and use a second invisible hitbox actor for the base, and also attach it to the main model actor by having it warp at the base of the model every tic. If you don't know how to do that, I can help you with coding the second warping collision box.

Collision aside, flagging the model actor as pushable looks pretty ridiculous, so I'm not sure why you did it. Pushing the giant obelisk around so effortlessly makes it look like Doomguy is Superman. Also, hitscans can pass right through the model actor. So I'd recommend using the following flags on the actor, to make it a proper static, solid object, these are the flags I use for my own immovable model actors :

+Solid
+PuffOnActors
+Shootable
+NoDamage
+NoBlood
+DontThrust

Not sure why you made the actor inherit from TorchTree either, if it was to be able to map the trees' one sprite frame to the OBJ model for your actor, then you could make a new "sprite", that is a transparent render of the obelisk in Eevee or Cycles, then map that new sprite to the model. That way the editor will also show a proper graphic for the obelisk in the Edit Thing window, as it currently just shows the sprite the model is mapped to, which is of course a tree. That render could also be used as the thumbnail for the submission. More specifically I'd suggest using a low resolution, paletted version of the render for the sprite, to save on file size, and then using the full resolution render for the thumbnail here.

Another thing you should add to the actor code is editor keys, so the actor has a proper name in the editor instead of just the class name, and so it appears in a folder besides the default User-defined folder for custom actors, such as on the Obstacles folder, here is the ZDoom wiki page on all the currently existing editor keys . The most relevant ones are //$Title, and //$Category, and maybe //$IsDecoration if you want it marked as such in the editor.

Now for the model itself, requiring the whole OTEX texture pack for the Obelisk textures is too extreme of a requirement, since OTEX is a 70 MB texture pack. And it may drive people away from using the resource if they aren't using OTEX for a map project already. So since the model only uses 4 OTEX textures, I'd be better to just ship them with the model itself. And on the subject of textures, when you start up GZDoom, it gives an error saying that the material OMRBLF01.003 doesn't exist, so either manually remove the .003 on the materials' name from the OBJ file on line 1105, or rename that material in your Blender project and re-export the OBJ to get rid of the warning.


However, I would suggest just converting the exported OBJ model to MD3, that way the model will also work in Zandronum, since the actor doesn't really use anything that can't be done in Zandronum, and it wouldn't even if you added the flags and additional hitbox I suggested. However if you do decide to aim for Zandronum compatibility here's how you can make the model into an MD3:

• To convert the model to MD3, use Noesis , alternatively if you are using a pre-2.8 version of Blender, you could instead get Nash's MD3 export plugin to directly export models to MD3.
• If you use Noesis to convert the model instead, here's what to do to properly convert it to MD3, use the -scale command in the export options to shrink the model, as it's just barely over the maximum dimensions of an MD3 model, which leads to the tip of the model getting crushed down if not downscaled, I myself used -scale 0.5 to properly export it. Also use the Rotate 90 and Flip UV's flags to export the model, otherwise it'll be exported sideways with wrongly flipped UV's.
• This is probably uneccesary for me to tell you, but since the model HAS to be downscaled with either method, scale it back up in MODELDEF. Also use FrameIndex instead of Frame after converting it to MD3, or else you'll get errors.

The above is basically what I did myself to convert your model to an equivalent MD3 by the way. However there is a problem with the model in-game that I couldn't figure out the solution to myself, so you may have to do it. But for some reason, in GZDoom, the MD3 model will stay at its' own scale, even when you upscale it again through MODELDEF, I'm not sure why that even happens besides just being a result of MD3 being a bad model format, since I've never had an issue like that before. Another issue is that in Zandronum, the MD3 model doesn't even render at all for some reason. However in UDB the model is rendered exactly as it should, including being scaled according to MODELDEF.

These are all the critiques and suggestions I have for the model, the last suggestion of converting the model for Zandronum compatibility is completely optional, especially if neither of us can figure out why the model renders improperly or not at all in GZDoom and Zandronum.

Thanks for the extensive feedback! I've reuploaded a new version based on that, but some thing still remain:

- I've added the required files to the ZIP
- PUSHABLE flag was an oversight, not intended. Other flags added
- I've redone the model from scratch as the original was janky and kept falling apart when trying to fix it. New model is smaller(roughly 256 height)
- editor keys added
- textures added
- usemtl fixed

Regarding the tree, yes, I used it solely to map it to something. I'm all for doing what you're suggesting, but this is the very first model I tried and am not really familiar with Blender just yet. So am not sure what is to do in Eevee. I've added the blender file to the ZIP just in case you wanna see though.

Similarly, the collision and warping an actor, I don't think I understand what needs to be done, so I would take any help, thanks in advance.

I will consider the conversion to MD3, though I'd like to first have it fully fixed as it is now.

The category name should be Decoration, Decorations is not an existing category name, which means GZDB/UDB will put the actor in a new separate folder. Also downscaling the model wasn't really necessary, you could've kept it at the same scale, then just converted it to MD3 in Noesis to fit in the dimensions of the MD3 format, and rescaled it back to the original size using MODELDEF. With the halved size having to make a separate collision box for the base of the obelisk is a bit more unnecessary too, since it was originally necessary because of how much space there was across the base of the model which wasn't occupied by the obelisk itself.

As for making a render of the model to use as a sprite to attach the model itself to and as a thumbnail for the resource here on the site.
If you don't know how to make a basic render, you first have to move the camera at a spot and angle you want and like, by the way, a shortcut to do that more easily is by CTRL+ALT+NUMPAD 0, which will put the camera at the spot and angle you are facing. If the scene appears to be gone or half faded away, then go to the camera objects' properties and change the Clip End to some really high value. Also in case you don't know already, you can press the number 0 on the numpad to enter the cameras' perspective, and the other numpad keys put the viewport in different orthographic directions around the scene.



For a render to use as a sprite and thumbnail here, I'd suggest changing the camera type to orthographic as well, if the orthographic camera is too zoomed in or out, then just change the orthographic scale property. Also don't forget to set the X Rotation of the camera to 0 in the generic object data properties tab. To get a proper side shot of the model instead of one looking above or below it.



As for lighting the model up for the render, just move out the light and change its intensity until it can hit the obelisk, or alternatively change the lights' type to a directional sun light, when you do that there should also appear a line attached to the light with a yellow dot on it. That is a visualization of the lights' direction, and the yellow dot can be grabbed and moved around to change the direction of the lighting.

Now that you have the camera and lighting set up, it's time to make a render of the model, before pressing the Render Image button or F12 though, a few things need to be set up, first of all, the render needs to be transparent, to make a render transparent, go to the Render Properties tab, and under Film, turn on the Transparent checkbox.


Then you can change the renderer that will be used to Cycles if you want, but keep in mind that if you don't have a very powerful GPU (Such as a mid-range GTX card for example.), then it will take some time for the image to be rendered. But if you've got a high end GTX card (Like a GTX 1070 Ti and above.) or any RTX card (Like my RTX 2060), then rendering the model in Cycles will only take about 5-10 seconds, at least that is unless you set the amount of samples to use for the rendered image from 128 to something ridiculous like 4096. If your GPU is too weak or you just don't want to wait so long to render an image that'll become a low res sprite and site thumbnail anyway though, you can just render the image in Eevee, and maybe turn some advanced options like screen space reflections and ambient occlusion on if you want.

Here is the image render I made myself in Cycles using the project file you included.

Thanks for the tutorial, really. It helped a lot.

I've made these changes:

- mapping to TorchTree completely removed
- editor keys fixed
- new sprite created for the obelisk (see above)
- converted to MD3
- added a second actor that gets spawned with the obelisk to improve the collision, it's now possible to step on the base 

I made it smaller on purpose, it felt a bit too big - this way anyone can make it bigger if they want. No need for rescale too. When I used the scale property, the model was ok in game, but in UDB the size was different.

It should be a little more wide and taller, so players don't clip inside the model:



Also, you should ALWAYS add the NOTAUTOAIMED flag to shootable props.

I've increased both radius and height of the blocking actor, there should now be minimal clipping. The flag has also been added.

I've also added two more variants of the obelisk - one without the base and one floating with some kind of magic:

The floating obelisk has the FLOAT flag, which doesn't need unless you want the obelisk to follow the player's z height.