...will now not be taking place.

If we let x = b - a from above, the end product of all the algebra is

(x . x) - (x . r)� / (r . r)

which gives the square of the shortest distance from the vertex at b to the line. You can get this by substituting the value of k back in and doing lots of expanding, grouping, cancelling etc. I'm going to take a short cut which explains it from a different angle.

We will look at projection: flattening the 3d space onto a 2d plane with our line sticking out as the plane's normal vector. Since this plane is perpendicular to the line, we can just measure the distance from the vertex to the line in this plane to find our shortest distance.

We will start with a simplifying assumption which we can generalize later: assume that r is a normalized vector (of length 1).

We can split x up into two components: parallel to the line and perpendicular to the line. We ultimately want the latter one, but it turns out the former is easier to calculate. The parallel component is in the direction of r with length |x| cos C. Because r is length 1:
|x| cos C = r . x ��� �(1)

So we end up with the parallel vector being:
(r . x) r ��� �(2)

To get the perpendicular vector we subtract this parallel vector from x:
x - (r . x) r ����(3)

This is the vector we want, so we just do the usual trick of taking the dot product of (3) with itself to get the length squared:

(x . x) - 2(x . r)� + (x . r)�(r . r) ����(4)

Under our assumption (r . r) = 1 so (4) reduces to

(x . x) - (x . r)� ����(5)

What happens if we relax the assumption? We need to divide the right hand side of (1) by |r|. We then have to divide (2) by |r| a second to normalise the additional r term. But because |r|� = (r . r) we can calculate the normalizing factor without any expensive square roots. If you work through equations (3) and (4) you should find the same cancellation of the latter terms occurs to get the formula at the top of the post.

After all that cleverness to avoid a square root, I'd still suggest doing one for this specific application. The key thing is that r doesn't change within your loop through the vertices. You can normalise r outside of the loop, and avoid a division operation within the loop. For models of 300 vertices I'm sure this will prove to be faster. So just use (5) with a normalised r.

PS: Why does func_ let me do   and • but not θ ? 

Thanks for taking the time to outline the whole process, Preach. I was going to reply yesterday, but it seems I can't even get my 3D Picker working to translate on-screen clicks into world coords.
I'm sure I just messed something simple up but I got frustrated with the damn thing and just went and mapped instead. :P 

Finally straightened out the screen coords -> world coords shenanigans and thanks to your posts, I now have vertex selection in the 3d view! :)

For edge selection, I'm thinking make a plane perpendicular to the camera, find the point where the trace hits the plane, then use the same stuff you posted above except in reverse-- find a perpendicular line of shortest distance to the edge from that point.

Face selection, again with a plane, this time of the triangle. Find the point where the line intersects the plane, then check if that point is inside all 3 edges of the plane. (make sure the intercept point is on the same side of all 3 edges as opposite triangle point of the edges). 

Good that all of that stuff is working. I thought of one need little optimisation for selecting the best vertex when multiple vertices meet the criteria and forgot to mention it. If many vertices are within n units of the line you are probably best off choosing the vertex which is nearest the camera (rather than just taking the first result on the list which might be on the back of the model and confusing). The neat thing is that in (5) we already calculate (x . x), so we can save that value for the best point so far, then compare it to any subsequent point which is near enough to the line.

Your plan for the edge selection seems sound but one warning - you will need to special-case the situation where the edge is already perpendicular to the camera, because when you project the line into the 2d subspace it will collapse into a point, meaning r goes to (0, 0, 0). The danger is that you will then attempt to divide by the length of that line's r value and crash because it's a divide by zero. Check for the zero length, in that case you need only measure distance between two points - easy! 

A couple more models coming from further experiments with gmax animation: a force-field effect and a smoke plume. Download from:

http://www.btinternet.com/~chapterhonour/effects.zip

There's a test map included, extract the whole thing to your quoth folder - the models themselves are in a folder called test (in the hope you'll remember to delete it once you've had a look around the map). As with the waterfall effect from a while ago, the models work in engines as far back as winquake but are better in something with interpolation and alpha support. 

... announcing a Quoth 3 mod ? <- just wondering :P 

Hm, those plumes look more like underwater plants to me. Very nice ones at that though. 

I was messing around with particles and getting nowhere. 

JPL: the only reason quoth is used is because you need some kind of mod to display custom models, and quoth has an entity which does it and most people have it installed. Rumour squashed! 

I am not trying to create a rumor, I was rather expecting a brand new update from the awesome mod to shake my inspiration that is today almost inexistent... :/
and now I am really really disappointed :P 

 

While I'm enjoying having a wizzy new website, I don't want to feel like I'm just linking to it instead of posting stuff here. So I'm going to share a motivating story and then link to a new article which relates to it:

I remember on several occasions running into an annoyance when creating a model. I would spend some time working in gmax on the model, sculpting and skinning it, until I reached the moment when it was finally done, and it was time to export to mdl format. Once I'd cursed and sworn my way through making the fragile conversion succeed, I'd begin the work in QME of getting the model finished off - scaling, rotating and positioning it correctly, adding animations, importing the skins.

The annoyance came when half way through this work in QME, I'd suddenly realise how much better the model would be if this part of the skin wasn't mirrored, or if I'd turned some of the edges the other way. The dilemma was choosing between foregoing these improvements, or throwing away all the work in QME so far to export a new version from gmax.

If you have ever had the same experience, or just want to learn how you might create a quake model without using QME, please come read the long article I just posted at
http://tomeofpreach.wordpress.com/2012/11/24/a-modelling-pipeline/
The idea is to generate mdl files from a series of compiling tools, rather like bsp files are made.

Also in the modelling category is an expanded article on "progressive enhancement" expanding on what I've posted about it here, and restored downloads of my two modelling tools qmdl and md3tomdl. The latter is an exciting new version of the tool, v0.2! It offers better vertex rounding, proper vertex normals and support for multiple surfaces in the source md3 file. To be honest I've been using 0.2 for years and never realised I'd kept it to myself.

That's not to mention the model category where I've been uploading stuff the past week. It's a roughly even mix of models from the old site, newer models which I've shared in this thread, and entirely new models which nobody has seen yet! In particular the "Map objects" category has the best of the goods. 

i love md3tomdl :) 

Gmax md3 and soooo many things too learn. After using Hammer for so long Gmax is a bitch. Just getting things to grid. I keep moving things I don't intend to. A whole new set of terminology 

Stick with it though, and don't forget to walk before you can run. There are thousands of wooden barrel models out there, but one which was made just for quake(and so presents no legal worries) would still be nice! It's pretty simple to model, interesting to unwrap the skin for, and then doesn't need any animation (which is the hardest thing in gmax).

I really should take that old gmax tutorial I had on one of the qexpo sites, and revamp it on the blog someday... 

New model time (although I posted previews of it years ago so it's only newly finished)

http://tomeofpreach.wordpress.com/2012/12/15/ogre/

It's a replacement ogre (which along with In The Shadows makes two in the past week, I know...) with all the usual skin map stuff. It's based off the ogre drawing metlslme did, which I was looking for in the screenshots thread earlier.

Bonus fun fact: this model uses less texture memory than the id ogre in 3d accelerated engines! The original ogre texture is 264x194, which gets rounded up to 512x256 - twice as much as the 256x256 of this model. 

And another model, one which might even be more interesting, although it was much less effort to make. It's a mapobject for adding fences and wooden logs to a map, with 4 skins which cover the main ID wood textures. Go take a peek and download it from http://tomeofpreach.wordpress.com/2012/12/16/fence/ 

Looks very cool Preach. I may have a use for a model like that soon. :) 

A model that has a lot of uses.
Nice.
Thanks Preach 

Here's a little bug, it won't attack unless you change its sting.qc.

bug

I wanted something that just flattered around,
but as it awakes it is fixed to a player.
Not what I expected as it attack routine isn't used.
Maybe make it a bit smaller to lower the bouncing box.
Odd when it isn't possible to jump over it.

download 

i haven't looked at the code, but movetogoal will home in on whatever entity is stored in the .goalentity pointer.

if you adapted the sting.qc from a normal monster, then you probably have ai_stand() in the idle frames which will set the player to goalentity when it sees them.

then you probably have ai_run(#) which uses movetogoal which is what makes it run to the player. 

I guess I should have elaborated more:

what you need to do is remove ai_stand and ai_runs.

you will need to make a new movement function to replace the ai_run.

then you will need to find a way to make it choose when to move and when to stand.

btw, the model is cool. :) 

You're aiming at the point I lost my intention, necros.

In the mdl is a subroutine that turns, so it must be possible to make it just fly around, and take a place to sit down, after continuing flying.

It's just that I'm not so familiar with monsters that won't get hostile.
The subroutine to make it only wandering around don't come with an example to reach it.

The tumble when it dies accordant to a scrag explains a bit of the way to go. 

Maybe the code I used for birds will be helpful?
http://mobile.sheridanc.on.ca/~jonescor/temp/ne_bird(07.12.12).qc

check out the ai_bird() function at line 373

The bird doesn't move on it's own. The mapper places bird_anchorPoint entities with flags set for either food or rest.

Birds get hungry and tired when flying and have to go to rest areas to remove tiredness and food areas to remove hunger. This is basically how they decide where to go.

Also, birds don't use movetogoal or walkmove, they directly set .velocity to fly around. 

I searched in the AI.QC the .goalentity and the void.Hunt target.

I thought it would be possible to make the entity not getting hostile with an exclusion, but there is more involoved.

Still I don't get it why I can't jump over it.
I made the so seize small and still it acts like a pillar.

Thanks for the util, will see it through.