Discrepancy if applying a scaling factor to rotation matrix

[sparhawk]

I created a model and put it into my map. Since this model is a pole, I wanted it to be larger then modeled, because it has to be used in a variety of sizes and I don't want to model it in all kind of lengths.

 

My first attempt was to apply a scaling factor in the matrix, which worked in DR, and the model got longer because of that. However, when I loaded the map in D3 the length was not applied, so it seems that D3 adjusts such values. Maybe this should also be done in DR? This could be achieved by clamping the absolute values between 0 and 1.

[greebo]

Which values do you refer to? The diagonal elements of the rotation matrix?

[sparhawk]

Yup.

[greebo]

So, what exactly does Doom 3 with the matrix? Does Doom3 ignore the values completely, or change them?

[OrbWeaver]

I would be tempted to leave this is a "change at your own risk" thing. If Doom 3 does not accept the scale matrix, then there is no reason for a mapper to manually enter it, and if they do they can expect strange results.

[sparhawk]

In principle I agree with you, but the problem I see is that it "works" in DR, and I assume that the editor for the maps would give me a reliable representation of the map as it will look in the game. As I said, if you clamp the values between 0..1 and keep the sign, it should be safe. You don't need to change the actual values, because D3 doesn't seem to do it as well. Only clamping the values while calculating the views should be enough.

[SneaksieDave]

Is the goal to disable the ability to use the rotation size hack? It does work in game (I've done it with DoomEd), but I believe it can be hard to get just right. If it's not really causing any problem, why disable a feature that can be useful? But maybe I'm misunderstanding the post.

[sparhawk]

Do you have an exmaple where it worked? Getting it right is not the issue. I adjusted the value so that it was right. Since I only had one axis where I wanted to adjust the size, this was quite easy to do. But when I load the map in Doom 3 the model has it's original size, so I figured it ignores that. I seem to remember that ascottk did this successfully somehwere, but I thought that this was not with the rotation parameter.

 

I can create a testmap and make a comparison, to make sure. Mathematically it should work, so if it doesn't then it means that Id disabled this intentionally for some reason.

[greebo]

Weren't there some other problems as well, like the clipmodel not being scaled along with the model or something?

[SneaksieDave]

@spar: Not a specific example built right now, but I recall resizing a table to be huge when we discussed it in another thread about this topic, long ago. There were some difficulties getting it right, and once I rotated the object in the editor, the scaling broke.

 

Hm. I wonder if they could have changed something with the patch?

 

@greebo: Yep, I believe so. In that case, rotate your model as you want it, do the scale hack, and then build a clip brush around it. *shrug*

 

Anyway, I just meant that we could always just leave it alone, leave it unsupported, rather than actually disabling it... it's got some use afterall.

[sparhawk]

If you use it for static objects that are outside accessible areas, tehn it should work. Might save some time, because you can reuse existing models in that case, but I guess that use is pretty limited. I will test this tonight though, and see if this really works or not. If this is clamped in the SDK code, then it must be done somewhere, so we should be able to find it. Mathematically it should work, because this matrix is nothing special. It's an effect of using these matrix operation, so you would have to specifically disable it as no extra code would be required to support it. I wonder why they don't apply the same rotation matrix to the climodel though. This would solve all issues, and IMO the climodel has to be aligned with the model anyway.

[SneaksieDave]

Just tried this out, and it works fine. I created two tables and scaled them with the rotation hack. The first image is after building the map in DoomEd and applying the scale to the first table, compiling, and then viewing it in Doom3. The second image is after closing, reopening the map in DarkRadiant, applying the scaling to the second table, saving, recompiling, and launching it in Doom3 again.

 

[sparhawk]

Don't know what I did wrong, but it works now. Anyway, the climodel is indeed screwed up I could walk through half of my model (I scaled it up by 2).

[SneaksieDave]

Yep, to get around that, one method would be just to make a brush of the same size and shape (roughly) around the object and texture it with collision or clip.

[jdude]

Just out of curiosity does the clip brush remain large when you shrink an object? If so that could be a potential problem.

[sparhawk]

The clip brush stays where you placed it. It's not related to the model. Only the climodel should be shrunk with the model, but apparently that's not the case. Don't know why, because IMO you would just have to apply the rotation matrix to the climodel as well. Maybe they skipped that part for performance reason and just copied the clipmodel to the same position, but I don't see how that should work.

[SneaksieDave]

It's annoying that T3Ed was the same way. There's got to be some programmatic reason behind it I assume, that they'd go through the work to allow for a visual size hack, but not go ahead and resize the collision info, too. It's a shame. Although, probably fixable at code release...

[OrbWeaver]

There is no work involved to allow the size hack, it is an accident of using a matrix to represent rotation since a matrix can also represent translation, scaling or shearing.

 

I have no idea why the clipmodel is different though, you'd think if the matrix applies to one it would apply to both.

[Fidcal]

Can someone explain to me exactly how to do this please? Specifically I need some large wrought iron gates so I want to enlarge the model provided then add an unrendered brush to block the player. The gates are purely decorative and will not be opened in game. But I can't find anything about rotation parameters nor do I understand how to do this tweak.

[SneaksieDave]

Pick your model, and give it a keypair of "rotation" "2 0 0 0 2 0 0 0 2".

 

That's a 3X3 matrix of:

2 0 0

0 2 0

0 0 2

 

Which scales it by two. You'll need to put in clip brushes manually to make it seem solid.

[Fidcal]

Thanks SD, Is there any way to change the height and width separately? I've been experimenting all afternoon and got double width and once I saw double height but lost my setting! Also got thicker railings in the gate for the same size gate!

 

[EDIT] Hang on - I think 1 0 0 0 1 0 0 0 3 might be what I want. I'll experiment more later. Many thanks.

[OrbWeaver]

The first non-zero number is the X scale factor, then Y, then Z.

[Fidcal]

Got it. thanks. What delayed me earlier was you don't even see the rotation values until you use the rotate tool and then you see something like 0.100146 -0.528522 -0.842992 -0.363242 0.769351 -0.525504 0.926297 0.358838 -0.114934 so it was not clear what did what.

[OrbWeaver]

Yes, that's why it's a hack. If you want both a rotation and a scale, you're going to have to multiply the matrices yourself (!).

[Fidcal]

The trick seems to be to first rescale manually and then rotate using the DR tools in the normal way.

 

[EDIT] As you were. The above is only true for 90 degree turns.