Per <a href="http://www.unknownworlds.com/forums/index.php?showtopic=108763" target="_blank">this</a> thread, will the engine support Level-of-Detail for models, or tessellation?
<!--quoteo(post=1750184:date=Feb 1 2010, 09:00 PM:name=Draco_2k)--><div class='quotetop'>QUOTE (Draco_2k @ Feb 1 2010, 09:00 PM) <a href="index.php?act=findpost&pid=1750184"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Per <a href="http://www.unknownworlds.com/forums/index.php?showtopic=108763" target="_blank">this</a> thread, will the engine support Level-of-Detail for models, or tessellation?<!--QuoteEnd--></div><!--QuoteEEnd-->
I'm fairly sure every engine in existence supports LODs, certainly for prop based levels like this it's ideal.
<!--quoteo(post=1750308:date=Feb 2 2010, 07:40 PM:name=Chris0132)--><div class='quotetop'>QUOTE (Chris0132 @ Feb 2 2010, 07:40 PM) <a href="index.php?act=findpost&pid=1750308"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I'm fairly sure every engine in existence supports LODs, certainly for prop based levels like this it's ideal.<!--QuoteEnd--></div><!--QuoteEEnd--> It would seem counter-intuitive not to have it, but it's not in the pre-alpha right now.
<!--quoteo(post=1751743:date=Feb 8 2010, 12:25 AM:name=Seker)--><div class='quotetop'>QUOTE (Seker @ Feb 8 2010, 12:25 AM) <a href="index.php?act=findpost&pid=1751743"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->How good will the engine handle LARGE outdoor levels?<!--QuoteEnd--></div><!--QuoteEEnd--> Just a hunch, but if they're really going for real-time portals, probably about as good as any game possibly could.
Inability to handle open environments was stated as one of the problems with the source-like precalculated visleaf system in the optimisation news post, that implies if not explicitly states that one of the reasons the realtime method was chosen was because it <i>can</i> do outdoor areas.
I can't speak from in-game experience of course, but I did just create a very simple test area that basically comprised of an enormous area with a few props and lights in the editor. In lit mode, the spark editor didn't even hiccup, where for me, creating a much smaller room and lighting it created noticeable amount of editor lag when moving. This is probably because the raytracing doesn't have to bounce around as many times, so maybe outdoor maps will be an unintended feature.
<!--quoteo(post=1751853:date=Feb 8 2010, 08:35 AM:name=Dalin Seivewright)--><div class='quotetop'>QUOTE (Dalin Seivewright @ Feb 8 2010, 08:35 AM) <a href="index.php?act=findpost&pid=1751853"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I can't speak from in-game experience of course, but I did just create a very simple test area that basically comprised of an enormous area with a few props and lights in the editor. In lit mode, the spark editor didn't even hiccup, where for me, creating a much smaller room and lighting it created noticeable amount of editor lag when moving. This is probably because the raytracing doesn't have to bounce around as many times, so maybe outdoor maps will be an unintended feature.<!--QuoteEnd--></div><!--QuoteEEnd-->
Max let away the "bouncing light" feature. (radiosity) So there is none.
It's because when you are at a certain distance from a light (distance being relative to the range of the light I think) It will stop casting shadow (even if it's set on).
So, in a smaller room you are surely close enough to all the lights for them to cast shadows.. and the shadow system right now is really demanding. Try not using many shadow-casting omnis.
I'm wondering if the editor will able to, during rotation, choose to rotate objects around a point or vertex? Will we be able to rotate selection by typing in the angle, instead of dragging it with the tool? Will the editor have more than one decimal on rotation? Co-sinus, sinus and tangent while rotating? Pi?
I've created a <a href="http://en.wikipedia.org/wiki/Truncated_icosahedron" target="_blank">truncated icosahedron</a> in Spark, but I don't think it's a 100% correct because the degrees between the hexagons are (not exact values, but still, better.) 138.18968510422140193 and between hexagons and pentagons are 142.62263185935030436. And with only 1 (shown) decimal in the editor, it all get's kinda skewed :p
<!--quoteo(post=1752725:date=Feb 12 2010, 02:49 PM:name=Dauntl3ss)--><div class='quotetop'>QUOTE (Dauntl3ss @ Feb 12 2010, 02:49 PM) <a href="index.php?act=findpost&pid=1752725"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I'm wondering if the editor will able to, during rotation, choose to rotate objects around a point or vertex?<!--QuoteEnd--></div><!--QuoteEEnd-->
You can do that with Cycle selection. Including a free vertex.
<!--quoteo(post=1752725:date=Feb 12 2010, 02:49 PM:name=Dauntl3ss)--><div class='quotetop'>QUOTE (Dauntl3ss @ Feb 12 2010, 02:49 PM) <a href="index.php?act=findpost&pid=1752725"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Will we be able to rotate selection by typing in the angle, instead of dragging it with the tool?<!--QuoteEnd--></div><!--QuoteEEnd-->
You can do that in Selection mode, while object is selected.
<!--quoteo(post=1752725:date=Feb 12 2010, 02:49 PM:name=Dauntl3ss)--><div class='quotetop'>QUOTE (Dauntl3ss @ Feb 12 2010, 02:49 PM) <a href="index.php?act=findpost&pid=1752725"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I've created a <a href="http://en.wikipedia.org/wiki/Truncated_icosahedron" target="_blank">truncated icosahedron</a> in Spark..<!--QuoteEnd--></div><!--QuoteEEnd-->
I don't why you need to create such thing in Spark. Plus, it will certainly be hard to texture correctly. If you really need anything that complex, I suggest you build it in any 3D modeling program and import into Spark with proper mapping coordinate, takes a min.
<!--quoteo(post=1752731:date=Feb 12 2010, 09:04 PM:name=Pipi)--><div class='quotetop'>QUOTE (Pipi @ Feb 12 2010, 09:04 PM) <a href="index.php?act=findpost&pid=1752731"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You can do that with Cycle selection. Including a free vertex.<!--QuoteEnd--></div><!--QuoteEEnd--> Not with geometry? <!--quoteo(post=1752731:date=Feb 12 2010, 09:04 PM:name=Pipi)--><div class='quotetop'>QUOTE (Pipi @ Feb 12 2010, 09:04 PM) <a href="index.php?act=findpost&pid=1752731"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You can do that in Selection mode, while object is selected.<!--QuoteEnd--></div><!--QuoteEEnd--> Still not with geometry :p
<!--quoteo(post=1752731:date=Feb 12 2010, 09:04 PM:name=Pipi)--><div class='quotetop'>QUOTE (Pipi @ Feb 12 2010, 09:04 PM) <a href="index.php?act=findpost&pid=1752731"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I don't why you need to create such thing in Spark. Plus, it will certainly be hard to texture correctly. If you really need anything that complex, I suggest you build it in any 3D modeling program and import into Spark with proper mapping coordinate, takes a min.
;)<!--QuoteEnd--></div><!--QuoteEEnd--> I'm not using it as a prop, I'm only using parts of it. I'm actually creating some futuristic windows, which includes a corner and a roof. =p It's pretty ambitious, but I think it will look good.
<!--quoteo(post=1752764:date=Feb 12 2010, 04:52 PM:name=Dauntl3ss)--><div class='quotetop'>QUOTE (Dauntl3ss @ Feb 12 2010, 04:52 PM) <a href="index.php?act=findpost&pid=1752764"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Not with geometry?<!--QuoteEnd--></div><!--QuoteEEnd-->
Yes you can. But you can't type an angle on a selection of geometry that I have to agree.
<!--quoteo(post=1752764:date=Feb 12 2010, 04:52 PM:name=Dauntl3ss)--><div class='quotetop'>QUOTE (Dauntl3ss @ Feb 12 2010, 04:52 PM) <a href="index.php?act=findpost&pid=1752764"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I'm not using it as a prop, I'm only using parts of it. I'm actually creating some futuristic windows, which includes a corner and a roof. =p It's pretty ambitious, but I think it will look good.<!--QuoteEnd--></div><!--QuoteEEnd-->
I would still consider making your futuristic windows (or any complex geometry) as a prop.
The algorithm they implemented (CHC++ iirc?) is one of the fastest realtime methods of culling. So outdoor environments should render just fine, just don't let aliens out there :P
slayer20Killed a man once.Join Date: 2007-12-13Member: 63157Members, Reinforced - Shadow
<!--quoteo(post=1753395:date=Feb 16 2010, 08:36 AM:name=Seker)--><div class='quotetop'>QUOTE (Seker @ Feb 16 2010, 08:36 AM) <a href="index.php?act=findpost&pid=1753395"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Is the max player number now fixed at 32 ?<!--QuoteEnd--></div><!--QuoteEEnd-->
I believe UWE is designing the game to be played with 16 players on both teams, however, modders will most likely be able to change this number.
<!--quoteo(post=1749833:date=Jan 30 2010, 01:12 PM:name=WhiteZero)--><div class='quotetop'>QUOTE (WhiteZero @ Jan 30 2010, 01:12 PM) <a href="index.php?act=findpost&pid=1749833"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Editor probably doesn't have it's own setting because AA in an editor is basically pointless. I'm sure they will have it in-game.<!--QuoteEnd--></div><!--QuoteEEnd--> If it uses deferred shading then it probably won't.
<!--quoteo(post=1753821:date=Feb 18 2010, 12:20 PM:name=Stardog)--><div class='quotetop'>QUOTE (Stardog @ Feb 18 2010, 12:20 PM) <a href="index.php?act=findpost&pid=1753821"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->In games like Stalker and UT3 AA doesn't work.<!--QuoteEnd--></div><!--QuoteEEnd--> Actually it does, on 8xxx series an up.
The implementation can be tricky, apparently: UT3 originally shipped without support for it at all, but then implemented it rather acceptably in the following update, whereas enabling AA in Trine is a way to sub-1-fps hell.
<!--quoteo(post=1745153:date=Dec 30 2009, 03:38 PM:name=Insane)--><div class='quotetop'>QUOTE (Insane @ Dec 30 2009, 03:38 PM) <a href="index.php?act=findpost&pid=1745153"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You don't need to enclose your level in geometry. There's not really any such thing as "leaks" in Spark.<!--QuoteEnd--></div><!--QuoteEEnd-->
I've had people ask and want to know on IRC how leaks work in the game. So I thought the best place to put this was here and use your quote, as we have a working example of such in the Alpha video.
It's around 00:35 and you can see there is no noticable impact on performance judging from the video. Below is a ripped 720p screenshot of where to look for the example,
Eye, you still need gemoetry walls for the culling calcualtions, Models wont block view and if they did it would not be a good idea cause there are plent of clumbsy ones that have gaps. They still might put a "nodraw" texture into the engine?, thing to use at the moment is the Dev Black texture (it's there but needs a material file)
Models only cull their own faces for sure but not other sperate objects behind them? You saying they can cull each other like a spanner model behind a barrel? This badly needs confirmation. Is it not easier on the cpu to make calculations from simple level geometry rather than complex models, i cant imagine the point in doing that. If it did is that not a waste if its checking if a Can/Catwalk/Barrel is actually blocking other things. I can understand doing it on a door model in Single Player but its rather pointless half the time in multiplayer cause it still has to perform well if another player is holding a distant door open.
i dont think there is anything more optimal than "nodraw" surfaces and the culling of back faces on models.
<!--quoteo(post=1754950:date=Feb 24 2010, 09:31 PM:name=SgtBarlow)--><div class='quotetop'>QUOTE (SgtBarlow @ Feb 24 2010, 09:31 PM) <a href="index.php?act=findpost&pid=1754950"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->So basicly, laziness comes before Performance<!--QuoteEnd--></div><!--QuoteEEnd--> Congratulations, you have grasped the core idea behind scientific progress.
InsaneAnomalyJoin Date: 2002-05-13Member: 605Members, Super Administrators, Forum Admins, NS1 Playtester, Forum Moderators, NS2 Developer, Constellation, NS2 Playtester, Squad Five Blue, NS2 Map Tester, Subnautica Developer, Pistachionauts, Future Perfect Developer
<!--quoteo(post=1754929:date=Feb 24 2010, 03:21 PM:name=SgtBarlow)--><div class='quotetop'>QUOTE (SgtBarlow @ Feb 24 2010, 03:21 PM) <a href="index.php?act=findpost&pid=1754929"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Models only cull their own faces for sure but not other sperate objects behind them? You saying they can cull each other like a spanner model behind a barrel? This badly needs confirmation. Is it not easier on the cpu to make calculations from simple level geometry rather than complex models, i cant imagine the point in doing that. If it did is that not a waste if its checking if a Can/Catwalk/Barrel is actually blocking other things. I can understand doing it on a door model in Single Player but its rather pointless half the time in multiplayer cause it still has to perform well if another player is holding a distant door open.
i dont think there is anything more optimal than "nodraw" surfaces and the culling of back faces on models.<!--QuoteEnd--></div><!--QuoteEEnd-->
While I don't know the specifics of how the algorithm works, I'm pretty certain the way it decides what is going to be culled means it wouldn't bother with culling a spanner sitting behind a barrel.
To illustrate what I mean, take a look at this shot of this hallway with occlusion culling cutting out the rest of the level:
The engine is still drawing some polies that are not technically visible (see <a href="http://www.unknownworlds.com/ns2/news/2009/3/occlusion_culling" target="_blank">the rest of the post</a> on OC for more details). Your spanner example would probably fall under the umbrella of polies that the engine chooses not to cull.
The only people I see suffering the most from the "Soup" theory might be low spec ATI users and there seems to be quite a few ATI users. nVidia users on X8800+ cards will handle this method flawlessly.
Comments
I'm fairly sure every engine in existence supports LODs, certainly for prop based levels like this it's ideal.
It would seem counter-intuitive not to have it, but it's not in the pre-alpha right now.
I guess we will see lots of mods but not all of them might be in some "sci fi space ships" :D
Just a hunch, but if they're really going for real-time portals, probably about as good as any game possibly could.
Max let away the "bouncing light" feature. (radiosity) So there is none.
It's because when you are at a certain distance from a light (distance being relative to the range of the light I think) It will stop casting shadow (even if it's set on).
So, in a smaller room you are surely close enough to all the lights for them to cast shadows.. and the shadow system right now is really demanding. Try not using many shadow-casting omnis.
Just got into playing monster hunter freedon, now go ahead and make a mod plx.
Will we be able to rotate selection by typing in the angle, instead of dragging it with the tool?
Will the editor have more than one decimal on rotation? Co-sinus, sinus and tangent while rotating? Pi?
I've created a <a href="http://en.wikipedia.org/wiki/Truncated_icosahedron" target="_blank">truncated icosahedron</a> in Spark, but I don't think it's a 100% correct because the degrees between the hexagons are (not exact values, but still, better.) 138.18968510422140193 and between hexagons and pentagons are 142.62263185935030436. And with only 1 (shown) decimal in the editor, it all get's kinda skewed :p
You can do that with Cycle selection. Including a free vertex.
<!--quoteo(post=1752725:date=Feb 12 2010, 02:49 PM:name=Dauntl3ss)--><div class='quotetop'>QUOTE (Dauntl3ss @ Feb 12 2010, 02:49 PM) <a href="index.php?act=findpost&pid=1752725"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Will we be able to rotate selection by typing in the angle, instead of dragging it with the tool?<!--QuoteEnd--></div><!--QuoteEEnd-->
You can do that in Selection mode, while object is selected.
<!--quoteo(post=1752725:date=Feb 12 2010, 02:49 PM:name=Dauntl3ss)--><div class='quotetop'>QUOTE (Dauntl3ss @ Feb 12 2010, 02:49 PM) <a href="index.php?act=findpost&pid=1752725"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I've created a <a href="http://en.wikipedia.org/wiki/Truncated_icosahedron" target="_blank">truncated icosahedron</a> in Spark..<!--QuoteEnd--></div><!--QuoteEEnd-->
I don't why you need to create such thing in Spark. Plus, it will certainly be hard to texture correctly. If you really need anything that complex, I suggest you build it in any 3D modeling program and import into Spark with proper mapping coordinate, takes a min.
;)
Not with geometry?
<!--quoteo(post=1752731:date=Feb 12 2010, 09:04 PM:name=Pipi)--><div class='quotetop'>QUOTE (Pipi @ Feb 12 2010, 09:04 PM) <a href="index.php?act=findpost&pid=1752731"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You can do that in Selection mode, while object is selected.<!--QuoteEnd--></div><!--QuoteEEnd-->
Still not with geometry :p
<!--quoteo(post=1752731:date=Feb 12 2010, 09:04 PM:name=Pipi)--><div class='quotetop'>QUOTE (Pipi @ Feb 12 2010, 09:04 PM) <a href="index.php?act=findpost&pid=1752731"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I don't why you need to create such thing in Spark. Plus, it will certainly be hard to texture correctly. If you really need anything that complex, I suggest you build it in any 3D modeling program and import into Spark with proper mapping coordinate, takes a min.
;)<!--QuoteEnd--></div><!--QuoteEEnd-->
I'm not using it as a prop, I'm only using parts of it. I'm actually creating some futuristic windows, which includes a corner and a roof. =p
It's pretty ambitious, but I think it will look good.
Yes you can. But you can't type an angle on a selection of geometry that I have to agree.
<!--quoteo(post=1752764:date=Feb 12 2010, 04:52 PM:name=Dauntl3ss)--><div class='quotetop'>QUOTE (Dauntl3ss @ Feb 12 2010, 04:52 PM) <a href="index.php?act=findpost&pid=1752764"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I'm not using it as a prop, I'm only using parts of it. I'm actually creating some futuristic windows, which includes a corner and a roof. =p
It's pretty ambitious, but I think it will look good.<!--QuoteEnd--></div><!--QuoteEEnd-->
I would still consider making your futuristic windows (or any complex geometry) as a prop.
Anyway, I can't seem to figure out how to rotate around a vertex. Care to show how?
I believe UWE is designing the game to be played with 16 players on both teams, however, modders will most likely be able to change this number.
I'm sure they will have it in-game.<!--QuoteEnd--></div><!--QuoteEEnd-->
If it uses deferred shading then it probably won't.
In games like Stalker and UT3 AA doesn't work.
Actually it does, on 8xxx series an up.
The implementation can be tricky, apparently: UT3 originally shipped without support for it at all, but then implemented it rather acceptably in the following update, whereas enabling AA in Trine is a way to sub-1-fps hell.
I want my AA. :(
I've had people ask and want to know on IRC how leaks work in the game. So I thought the best place to put this was here and use your quote, as we have a working example of such in the Alpha video.
It's around 00:35 and you can see there is no noticable impact on performance judging from the video. Below is a ripped 720p screenshot of where to look for the example,
<img src="http://img43.imageshack.us/img43/4913/void1y.jpg" border="0" class="linked-image" />
They still might put a "nodraw" texture into the engine?, thing to use at the moment is the Dev Black texture (it's there but needs a material file)
This badly needs confirmation.
Is it not easier on the cpu to make calculations from simple level geometry rather than complex models, i cant imagine the point in doing that.
If it did is that not a waste if its checking if a Can/Catwalk/Barrel is actually blocking other things.
I can understand doing it on a door model in Single Player but its rather pointless half the time in multiplayer cause it still has to perform well if another player is holding a distant door open.
i dont think there is anything more optimal than "nodraw" surfaces and the culling of back faces on models.
I'm rather appreciative and think it's a pretty good idea that meshes and geometry act in a similar way.
Congratulations, you have grasped the core idea behind scientific progress.
This badly needs confirmation.
Is it not easier on the cpu to make calculations from simple level geometry rather than complex models, i cant imagine the point in doing that.
If it did is that not a waste if its checking if a Can/Catwalk/Barrel is actually blocking other things.
I can understand doing it on a door model in Single Player but its rather pointless half the time in multiplayer cause it still has to perform well if another player is holding a distant door open.
i dont think there is anything more optimal than "nodraw" surfaces and the culling of back faces on models.<!--QuoteEnd--></div><!--QuoteEEnd-->
While I don't know the specifics of how the algorithm works, I'm pretty certain the way it decides what is going to be culled means it wouldn't bother with culling a spanner sitting behind a barrel.
To illustrate what I mean, take a look at this shot of this hallway with occlusion culling cutting out the rest of the level:
<img src="http://www.unknownworlds.com/files/ns2/occlusion/occlusion03.jpg" border="0" class="linked-image" />
The engine is still drawing some polies that are not technically visible (see <a href="http://www.unknownworlds.com/ns2/news/2009/3/occlusion_culling" target="_blank">the rest of the post</a> on OC for more details). Your spanner example would probably fall under the umbrella of polies that the engine chooses not to cull.
nVidia users on X8800+ cards will handle this method flawlessly.