[QUOTE=Emon and Zanardi]Lighter plugin[/QUOTE]The shadows ain't even that great, I like the way the lighting is gradual. And there isn't bugginess

of course it would - that's why the 'decor' 3do version of the level is there. the engine ends up drawing the same surfaces as it would have otherwise, right? essentially you're "turning off" the level for everything except collision detection to get rid of the collision detection issues associated with some 3dos.




you've been misled. since you referenced OGL, i'll reference it as well: i took a class that was taught by the fellow who wrote the OpenGL Superbible. he even went into depth about different types of geometry culling; including occlusion culling. here's wikipedia.org's definition of occlusion culling:

http://en.wikipedia.org/wiki/Occlusion_culling
Occlusion culling
Occlusion culling is the process of determining which portions of objects are hidden by other objects from a given viewpoint. This is one of the fundamental problems in computer graphics, and many different occlusion culling algorithms have been developed. The simplest is painter's algorithm, in which polygons are sorted, then drawn back to front. The most common in real-time computer graphics is z-buffering, in which the depth value at each pixel is stored as each polygon is rendered. The pixel is only overwritten if the depth value of the current point is less than the depth value stored in the z-buffer. Both of these methods operate on polygon meshes.

all the talk about drawing polygons and Z-buffer in that description are simply the means that occlusion culling operates. that's why I highlighted the 'polygon meshes' part. and just to clarify, wikipedia.org also defines a polygon mesh as the following:

A polygon mesh is a collection of vertices and polygons that define the shape of an object in 3D computer graphics.

like i mentioned in the last post: there is no 'occlusion culling' for individual surfaces; unless you count the z-buffer, which doesnt gain you any performance since, again, you are still rasterizing the full polygon.



wikipedia is great:
http://en.wikipedia.org/wiki/Portal_rendering
Ideally, portals are formed of confined areas (like doors or tunnels), connecting two complex areas of the level, where each of these areas would be enclosed in such a polygonal body.

Portals are best suitable for indoor scenes such as mazes. Outdoor scenes do not usually have door-like objects that would clearly separate one sector from another.

regardless of the number of surfaces actually culled, the point of cell and portal is to cull LARGE amounts of geometry. performing a HUGE breadth-first traversal through hundreds of portals just to save rendering a few hundred polygons is NOT worth the performance cost of doing the traversal. unless you're running in software mode, you're not going to get a huge performance hit by having a bunch of overdraw.

sorry to preach, but most of you guys really don't seem to understand that visibility determination is not all-powerful. rendering polygons is not the most computationally expensive operation out there. we have DEDICATED hardware for rendering polys, NOT for performing visibility determination - why chew up both that AND the cpu? instead of having the CPU bust its butt trying to save the poor gpu from working too hard, give it something more important to do: like world simulation.

i've been in the gnitty gritty with CP vis det. i've written both a 3d version AND a 2d version (demonstration of the algorithm for a school project).

ta da, i just sat down for a couple hours and wrote it.


'Sector-to-Mesh' is a dll plugin for jed, the full sourcecode will be released with the plugin.

highlight any number sectors/surfaces and click 'Add selected surface(s)'. repeat as needed. when done, click Export 3DO.

BAHHQ.jkl


BAHHQ.3do

I could think of a simpler way... Multiselect sectors, switch to surface mode, press ALT+I. Export sectors as 3do. With the exception of translucent adjoins, that would handle most of it. In JK's case, saving those few polygons would be very useful. After a couple thousand, JK's framerate degrades rapidly. Either way, knowing Daft, I'm sure he knows what he's doing with the architecture, so it should be fine as it is. As for the level, it reminds me of some of those Escher drawing. Just does. Not that that's a bad thing.

first of all, you wouldn't want to invert the surfaces.

there's a couple problems that could make a plugin to do it still useful.

1) 'Export Sector(s) as 3DO' does nothing unless you are in sector mode. Individual surfaces cannot be selected for export.

2) The plugin gives you more freedom over which types of surfaces to extract. Adjoins, invisible or translucent surfaces, or surfaces flagged as sky (for example) could be skipped very easily. Even surfaces assigned to COG.

3) Any types of surface changes could be made to the specific surfaces exported (like geo 0, no adjoin visibility)

Actually, you do need to invert the surfaces. Try it and see for yourself.

The level's looking nice so far.. I will be following the thread and look forward to seeing the finished product

SIM_BLIMKE's level in MLP2 suffered from this.. I can't remember if it was fixed, but I put my thumbs down to 3do levels. They don't 'feel' as solid and I believe they are not as challenging to make.

the purpose of creating a 3do level, at least the type we're talking about, is not to simplify the process of creating the level (in fact it takes more work). The collision detection might suffer, but i've already proposed a way to use the original level geometry for collision detection and still gain the performance benefits of not doing an overly intensive vis det.

And yeah, I guess you're right about the inverting surfaces thing, i forgot that exporting as a 3do will invert them automatically to make 'solid' shapes.

Don't 3do the level it will ruin it. Anyway it's fine how it is.

The adjoin limit patch has removed any need for a 3do level.

Actually, it's probably just bad coding. Either way, it didn't make complex levels run faster; it made complex levels ugly. It might have kept some stuff fast... a decade ago. But now it's 2006. We can render the most complex JK levels at hundreds of frames a second. Who needs the hard limit?

how do you figure?

Yeah, I'm still sure this wouldn't work well. There are usually many seams between the surfaces of 3dos.

This was really the least important part of my argument. I merely thought that the painter's algorithm culled occluded polygons, not occluded polygon meshes, and that Occlusion culling referred to such polygon-exclusive methods. My mistake.

That Wikipedia quote only cements my point. If you're making a level with many interior spaces, portals works significantly better. However, I am not deluded enough to realize that 3dos would almost certainly be the best method for creating a vast landscape.

If a level were boxy with only a few hundred surfaces or all the surfaces were visible, I'd agree with you. But again, having thousands of polygons rendered simultaneously when they could be culled is just stupid.

Cool beans. I programmed a symphony out of computer beeps with BASIC

Hardly.

daft could you do me a favor?

1) save a backup of the level
2) position the walkplayer in a good spot for testing framerate
3) set the geomode to 0 for ALL SURFACES (yes this will create complete HOM)
4) test the level and tell us the framerate

you won't be actually rendering any surfaces (except for the player model of course), so according to these guys you should have hundreds or thousands of frames/sec.




actually it is GOOD coding practice to impose hard limits to keep subsystems within their bounds. Nine years ago, this made perfect sense. If a level designer tested their level and got HOM, they knew the level was too complex to run on the target platform.

Did LEC release their level editor so people could continue making levels over the past nine years? No. Did LEC release any types of expansions or level packs (after MOTS of course) for JK in the past nine years? No.

They had no reason to remove hard-limits for the editing community, because they didn't fathom that they would HAVE an editing community (or at least weren't planning on supporting one). The originally hard-coded visible adjoin limit (more realistically, a traversal limit) had no ill effect on any of the levels officially supported by LEC.

Finally, i'm really curious what the guy who said this level is an indoor level has been smoking. what in god's name is your definition of an outdoor level?





all in all folks, this pointless bickering really doesn't matter. the real point is simple and unarguable: people should not be making DETAIL geometry out of sectors. that is what 3dos are for.

Theres nothing wrong with doing detail with sectors. Nothing wrong at all! In many ways, it is far superior. All the reasons not too have been removed from us. You can't win an argument just be declaring it over, ya know.


Or they could have tested it on the target platform, and see if it was too slow, like every other game company ever.

Agreed, but it's a shame that 3DO lighting sucks so much. Sometimes you have no choice.

As far as I understand, a portal engine is based on recursion, which means, that a lot of sectors can lead to serious problems. And, as you might know, recursion complexity is not linear to the number of base items (this means that a level with double the sectors would have much less than half of the framerate, if framerate was only dependent on this one algorithm).

Visually superior, perhaps. But JK's visibility algorithm is in real time, not precompiled like Quake, for example. Even then, detail brushes are used to cut back on the number of portals generated. 3DOs server a similar purpose.


But static allocation is cool, durr.

Wait, are you referring to me? It'd be helpful if you were more specific like "the guy whose post I completely ignored".

Whatever, who the **** am I trying to convince anyway? Just some guy who sucks at reading comprehension.

Is this thread still about Daft's level?

Quick Daft! Feed them another screenshot! They're turning savage on us!

No no no, make a new thread.

*Quotes Austin Powers*

Nerd Allert!

Seems all the level showcases turn into discussions or arguments between 2 or more people, kinda ruins everything.

So like, make another thread or something...

They did plan on an editing community, and did support it from what I know, just unofficially.

Actually, no one said that. The closest was to such a suggestion was you.

Yay, wonderful, joy! Now we just can't see the enemy player one sector over. Or that shot we fired off half a second ago. But if we're lucky, we'll get a few more frames before that random shot fired from a few sectors away kills us.

As I've said, I'm sure Daft knows what he's doing, and however he does the level, it won't be murderous on our framerates.

How the hell are you doing those lightning effects?

So what? Those limits were imposed when a PII was top of the line and 500 mhz was ungodly fast. Today, glacial machines have three times that power and a normal machine is in the 2-3ghz range.

Now, I'm not saying that the chair sitting in the corner shouldn't be 3dos. But there is nothing in this level that would benefit in any way from being made into a 3do. It's not even all that complex, where did this idea come from in the first place?

the same way everyone does them.. the wonderful lighter plugin

Give me more juicy updates! I demand them!

I've been trying to figure that out the past two pages.

I'm not dead yet.

Holy frick. Looks so much better textured..I didn't realize how nice it was until now.

#$*&@#$ assassins.

Nice, by the way. And the textures are just great.

Daft, you should try Zeqs new Patch, it would make this level look soooooooo hawt. My nipples get hard just thinking about it >.>

Yeah. The textures wouldn't have to tile so much, look MUCH nicer. That's my largest complaint actually is that I can see where that floor mat begins to tile again and again and again.

**** me. Right now.

Excellent, This is definantly your best looking map I've seen. I'm excited to see how the gameplay will be.

Holy ****. Just holy ****.

Holy **** that looks awsome!

I do have one query though, that piece of wall connected to the red roof looks a bit out of place.

That looks damn fine. Damn fine, my friend.

i don't think tiling will be that much of an issue when you're actually playing in the map, as opposed to floating high above it.

Excellent.

I actually preferred it without the textures, the white/grey Escherish look. As for the floor texture, there seems to be a gradient, brighter on one end, making a visible line which decreases its tilability.