I repeat myself: NO commercial engine is stupid enough to render anything outside the player's FOV. Not even the JK engine.

I was under the impression that it may, because it was suppose to render things in currently viewable sectors or some garbage like that. So I was thinking for huge outdoor levels you might have that problem. But as you said, it should already be built in.

The GeoMode 0 thing would work nicely for JK based things, but to really polish off a Mod, I'd strongly reccomend using JKs LOD system. Here within a few weeks, Shred is going to need a LOD maker (doing it by hand stinks) and since the no thing limit is around, it'd just be a really good idea. What I'll have it do, is let you select a model for each LOD, then it'll make an uber LOD capable 3do.

If I knew the algorithim for decreasing faces while keeping the general model shape, I'd just have it automatically make the best optimized LODs out of one base model. I'll look into that.

Thats what I've been saying all along in this thread. There is no need to destroy things anymore in order to protect framerate, or obviously beat the thing limit. If for some reason JK renders things that aren't visible (I really don't think so, but maybe) then a variation of the cog that turns off rendering rather than destroying things is the way to go. As far as the turning off rendering on distant objects...I think that would only be worth it on very slow computers or when the level featured a fog effect. I always hated when things phased out of existence when they got sort of far away in other games.

I agree with zagibu though, no graphics engine that is worth its salt (And JK's engine was, when it was released) should be rendering objects outside the players FOV to begin with. Its just bad coding. Perhaps JK renders objects that are in all sectors that are viewable though. That seems like sloppy coding as well, but who knows.

Y'know, JK just might render everything thats in a sector if that sector is viewable..... It makes sence from the problems I've encountered in the past. If you think of the way JK reacts when you put a 3do across multiple sectors, and how its only viewable if you can see the sector of the 3do, it would make you believe that JK is rendering things in sectors it can see, reguardless of if the camera can see them. I dunno now.

There are many modeling programs that allow you to decrease faces in a LOD sort of fashion. I don't have any of them, but ask someone knowledgable in 3DSMax.

JediKirby

My cohert in crime fits that description.

cohort lol

It might on a top level, but any vertices outside the viewing frustum should not get rendered. Try making an ubershpere 3DO (millions of faces or something) making it translucent and making a few dozen of them. Place them in the level, and you should see the framerate drop. Turn around, if the framerate is still low, you can tell.

Bah, I know a definate answer to this. The TDiR level I was testing a few no limit things in is just one big sector. I had a beam with 1000+ tail pieces with some framerate loss, when I looked away from it, the framerate was restored to normal.

Heh, der. _-_

(Don't ya hate it when you forget crap like that due to having 1,000,000 other things going on?)

The only problem with using JK LOD system is that it limits you to one set of values. For instance, in an outdoor level: Grass and Floral should be fade in/out at a shorter distance then trees, rocks, houses, and other static objects; and they should fade in/out before the terrain does. That's at least 3 sets of LOD values. (For an Indoor level, such as a Hoth based level I was working on, you'd want the 3do walls to render before the wall piping, crates, etc; and you'd want them to render before the small control pads, crushed hand-held items, etc).



That would be very useful and would save an incredible amount of time!

By the way, I'm running into a limit of JK in which if you have a sector that is greater then ~800^2 JKU's, a sprite-like surface is generated in front of the player the produces the HOM effect. Getting around this limit would be incredibly helpful.

Emon, I'm not protecting the RVTCS in any manner. Simply speaking from over 3 years of experience using it. If setting up LOD's in JK wasn't so tidious (and prone to currupting the 3do file), I'd like to see the RVTCS be modified to perhaps force LOD for each 3do (though, I'm not sure that's possible).

Geeze, I should check threads like this more often.


Let me clear a few things up here... JK has no need for a TCS (Thing Creation System, a term I coined if I recall correctly) anymore. None whatsoever. The sole purpose of a TCS is to get around the thing limit. Thats it.


The original TCS was over-convoluted, complicated, and doomed to failure. Implimenting it was a pain in the ***, and I never could get it to handle doors properly. (on the other hand, though, it was perfectly scalable... :D) And it, of course, relied on adjoins to trigger the creation/destruction of objects. Such a cog would be useless for outdoor archi, so Friend14 asked me to write a version that relied on the position of the player instead of adjoins. And thus, the RVTCS was born.
(actually, the original TCS wasnt just one cog - it was dozens. Cogs to handle adjoins, actors, doors, even cogs for cutscenes. Everything in the level was controlled in some way by the TCS... Like I said, complicated.)

But even the RVTCS, in its original form, isnt needed anymore. Version 3, however, does not actully create or destroy anything. It merely toggles an object's visibility. This cog still has a use - large, outdoor levels where too many things might be visible at once. But all the other TCSs, mine, Grismath's, can be silently forgotten.


Let me say it again for the skimmers and the logic impaired: JK has no need for a Thing Control System anymore. HR's patch quite effectively renders them obsolete and useless.

Actually, Grismath's may still have use for now. As the patch still isn't available to MotS. (I'm assuming Gris' would be for MotS since it's all he works in...).

Uh, you should check the no limit patcher thread again. :p

Ok, hadn't checked that. Then no, not really need for Gris'. Interestingly, I'm going to have to make one myself. (Same locations with changing items/setups, and adapting difficulty)

is version 3 just as much a pain in the *** to use? As well, since we're having issues with the AIs working after the normal thing limit, could it turn off and on AI?

Maybe there's another limit you could edit. The number of ai classes running at the same time. Just a thought.

From the way he was talking about things, it would seem JK just has a list/table that has a finite size for things, cogs, 3dos, ect ect. I would assume bypassing the file/variable type limit would be similar in fashion to bypassing the thing limit.

Anyway, I think he's taking a break from all of this for now.

1) Nay, its quite easy to use.
2) Sure, with a little tweaking.

Easy... but time consuming, no?

Not so much. If you're just changing the rendering factors, you can just enter the thing numbers. If you really wanted to make it fast, enter all thing numbers except walkplayers, I think.