New Age

[ZURI]

Hey all. I'm new here, obviously, and have jumped into Blender. I'm getting the hang of it and have been working on modelling a Sinister/Quasi-Evil looking temple for the Age I'm working on. I may be getting way ahead of myself in this, and I think feedback may be very beneficial to me. Reason being, I used the subsurf modifier on it several times. Will this kill framerates for players with older machines? I don't have a slower computer around to beta-test models/maps on, and am concerned - don't want to get too far and have to redo it all. However, I didn't spend an arm and leg building my dream computer to design something that looks like Quake 2......

Sorry it's a cruddy pic, but I've worked my tail off on it (mostly because I'm still learning Blender), and am kinda proud of it.

[Chacal]

Your model is beautiful.
But yes, subsurfing will kill the framerate on lots of computers, not only the low-end ones.
You want as little polygons as possible.
Especially for meshes that have collision.

Smoothing out shapes is better achieved with lighting, shadowing and texturing.

[kaelisebonrai]

Looks good for a first model, but, yes, the subsurf modifier is probably going to eat people's PCs for breakfast.

Subsurf is *great* for pre-rendered stuff, mostly. But really horrible for real-time 3d things like Uru. I'd recommend trying to see how nice you can get things to look, with the lowest amount of "faces" you can get. (It is shown in the upper right corner as "Fa:(number)" ).

[boblishman]

also ... (IIRC) PyPrp has a export limitation of around 8,000 polygons per object... so make sure that none of your objects have more than 8000 polygons or your age will not export.
However, don't use this 8,000 as a guideline figure to work towards .... it is a maximum, and you should probably only get near to this figure with very large (usually landscape) meshes.
This is one of the most common errors when people start age building ... making beautiful models that Uru chokes on. Low polygon 3D game modelling is almost an art in itself. As Chacal says, the "trick" is to use textures for details. You were completely right to ask your question early on in your creation process ... this may have saved you a lot of heartache

IIRC, Relto has a grand total of under 100,000 polygons ... (now that includes everything) ... so, that would only "allow" you only 12 objects of 8,000 polygons ... ... so you see, the lower poly your models, the more you can have ... (that's the real incentive of learning to model-make in low poly) ...

Take a (fresh) slow walk around Uru ... looking at the actual models (and not the textures) ... you might be surprised at just how low polygon most of Cyans models are ...

[ZURI]

Wow, I'm glad I asked!! Thanks folks, I learned quite a bit from this little exercise. The original (posted here) has 827 faces and 757 vertices. The modified version (earlier post) has some 53,000 faces and as many vertices! So, I take it the subsurf modifier is not optimized for level creation? On youtube there are a few terrain tutorials that recommend use it. Is this a hardware or URU/Plasma limitation?

The bad part in all this is, I've spend a good deal of time making the landscape that I wanted. It will all have to be redone. The good news is, I need the practice anyways. Right? Time to go brush up on GIMP. Thanks again!

BTW, does Plasma support multi-threading and Crossfire/SLI?

[diafero]

Welcome at the GoW, I'm looking forward to seeing more nice models and maybe complete ages from you

Is this a hardware or URU/Plasma limitation?

This issue affects each and every game and all the graphics cards out there. If you do a statically rendered picture, or a pre-rendered video, it is ok for that to take a while - just compare Myst IV graphics to Uru. However, if you design a 3D environment for Uru or any other real-time engine, the PC has to render *at least* 20 frames per second - in each situation, no matter where the camera is looking to.

does Plasma support multi-threading and Crossfire/SLI?

Not that I know of. Especially the single-threading is really annoying - if the engine is loading a page into memory, it does not even respond to network messages, so it seems to be completely dead for the server.

[ZURI]

I appreciate the info. It did seem a bit odd to me that I can run Crysis with higher visual quality than URU and get similar game performance. I'm running URU maxed, and the only times it lags at all is Eder Kemo during thunderstorms and (with the offline KI) Relto. I've played other games with environments similar to these, without any lag at all (Crysis, Fallout3, Oblivion etc.). This is why I was wondering about Crossfire/Multi-threading. Do any of you gurus out there know if Cyan had any intentions of adding these functionalities to their engine? Sorry about the wishful thinking, but it would be truly awesome if they did.

Since, apparently, I need to learn to make custom textures for my models - should I use GIMP? I have a copy of Photoshop 7, will it do the trick? It was released around the same time as URU, so could it be the program that Cyan used? I don't mean to be a pest with all of these questions, but I prefer to shorten the learning curve as much as possible. If I don't have to spend the next month learning GIMP, that would be great!

[Chacal]

The version of Plasma used in Uru:CC goes back to around 2003. The version used in MOUL (which we may use if Cyan releases it as open source) is newer but I doubt it is as modern as you hope.
Cyan has no stated intentions to add anything to its engine, since they're fighting for survival right now, and have decided to release the source code anyway.
However, if Cyan continues to make games based on the Plasma engine (such as this Magic Quest thing they're doing right now), it is possible that they will come up with new versions of Plasma. They could decide to release the code for that, too. Or not.

I appreciate the info. It did seem a bit odd to me that I can run Crysis with higher visual quality than URU and get similar game performance. I'm running URU maxed, and the only times it lags at all is Eder Kemo during thunderstorms and (with the offline KI) Relto. I've played other games with environments similar to these, without any lag at all (Crysis, Fallout3, Oblivion etc.). This is why I was wondering about Crossfire/Multi-threading. Do any of you gurus out there know if Cyan had any intentions of adding these functionalities to their engine? Sorry about the wishful thinking, but it would be truly awesome if they did.

[ZURI]

Ok, well at least I have a better understanding of what I'm working with now. One more question and I'll leave you all alone and get back to work. I used UV Unwrap to texture the Low Poly model. As you all know, it "unwraps" the brush and shows all the facets in 2D. Honestly, I'm not really sure how I should proceed from here. I know that I can export the 2D version into Photoshop to make the texture. My problem is that I'm having trouble scaling the textures that I would like to use onto each facet.

Can I, or rather, should I produce the model in it's entirety then texture it? Or can I build the model in increments, texture each increment - THEN combine them to make the final model? This seems a bit easier for me to do, but I'm unsure if it will work.

What I mean by this, is if I do it in stages then join it all together, are there ramifications that I'm not currently aware of? Will the textures still map to the individual faces, or will Blender want one big image? If this doesn't make much sense, I'll try to reword it in a later post.

Edited

[Jojon]

First of all; as you have seemingly alrady figured out, the textures are just pictures, so you can paint/edit them using any tool(s) you prefer.

On how to map them; that depends a bit on what you intend for the texture to "do".

The UV-map, that is created when unwrapping, is fully editable: when you select faces on your model, those same faces will show up overlaid on the texture in any "Image/UV-editor" window you have open and there you can grab hold of corners and move them around, just like the vertices they correspond to in the 3D view.
You do not even have to keep neighbouring faces connected in the UV-map, but can move them around independently, so that they may display parts of the texture that are set far apart, or exactly the same part.

Another thing to keep in mind, is that the texture tiles. I.e. any part of the map that falls outside the bounds of the picture in the UV-image editor, will still show up the texture, as if it repeated infinitely all around the "central" copy.

One important thing: any four-sided polygons you have, are actually two triangles put together. Not only does that mean that any non-flat "quad" will be convex or concave, depending on which way it is "cut" into those two triangles, but texture deformation will also depend on this: if you grab one of the corners not shared by the two triangles and drag it around, the mapped texture will not stretch across the entire "quad", but only the triangle half you are modifying.
I'm not sure that's a good explanation - you might try mapping a single plane and try fooling around with the UV-map to see the effect for yourself. (remember to tick the View->"Update automatically" menu item in your "UV/image editor" window. This will make your map updates reflect real-time, in the 3D-view)


I think I'll blabber no more right now, but instead wait and see whether this clears some things up and/or raises any follow-up questions... :7


Looks like you could safely use at least one, or maybe two levels on subsurf on that base model, by the way. You may want to be selective on where you have much detail and where you don't -- figure out what you will see up close and spend your polygons there. Things that you will only be able too see from a certain angle are prime candidates for replacing geometry detail with a texture which has shadows and all. If we ever figure out how to get normal maps (wherein each pixel tells which direction it is supposesdly facing, rather than a colour) working, we should be able to do this decently, even with dynamic lighting. :)