Source 2 hints unearthed in Filmmaker files

[Epifire]

They'll dump VVIS, and use a more modern occlusion culling system.

Suddenly source will be competitive again.

Stuff like that and a much better BSP workflow would be awesome. For some reason I am wondering if they will make some nifty GUI for importing/exporting models. Been long enough to where I think it will be one of the top competitor engines once again. Only thing is I recall a direct question to Newell from a interview about a year back and he sorta denounced any kind of broad step like this. He said source would be upgraded bit by bit as they saw fit in simpler terms. Now their strategy might have changed by now, or that was just a farce to throw the listeners off their trail. Why they gotta be so secretive I don't know, but I will be back to add in the video I found that from if I can.

Okay so I found it. I have used this as a reference of Gabe's words a lot for some reason...
http://www.youtube.com/watch?v=DMgfPU9y3yo&feature=player_detailpage

Go to 14:43 to where he talks about that to see a bit of what I mean. Maybe a whole engine upgrade resides under one of the, "fundamental upgrades" but no way to really be certain I guess.

[Gary]

They'll dump VVIS, and use a more modern occlusion culling system.

I was thinking the same. Since they will probably ditch the bsp system.

Its amazing how much of the engine depends on bsp. Not just VIS. Even when the engine looks up stuff to render it goes through the bsp trees. I wish this was better documented on the VDC.

[Epifire]

Unreal still uses small structural dependencies on BSP do they not? For some reason I still wonder why BSP could not be optimized to be more of a in-level editor model application like it used to be thought of. Mainly just really nice and effective tools for making really detailed structures without having to leave the editor.

Thing is currently the tools are not really geared for that, and the engine would bottom out of you tried detailing everything in that manner. I think there is a limit to how much detail should be summed up in the editor, like I don't think that making chairs and high detail props would be the correct way to use it. But mainly making really nice levels and structures that feel less blocky without constraining the engine resources.

That or just re-design with a much better optimized model creation pipeline. XD

[Stormy]

As if Valve would have let that slip without expecting it to get found. Who writes "next gen" in their code comments, and "source 2 tools"? Come on, valve love generating hype. Its bound to happen eventually but I wouldn't start raving just yet. Give it three years. It's got UE4 to contend with, I think it'll need a whole lot of work.

[MaK]

I heard about this a while back on facepunch, but this looks like pretty compelling evidence. The code about the l4d2 port onto the hybrid engine I find pretty interesting, it's like hl:source all over again. You might be able to infer what they are doing and not doing with the new engine assuming the l4d2 port was an easy transition. Still keeping my hope in valve this should be pretty exciting, but I wouldn't expect anything soon.

[Epifire]

If it is like the Source release then I would expect to see something industry defining all over again. But as you said Mak I don't expect to see anything soon either. I think HL 3 is gonna be on it's initial release. Would totally blow people away like they did before.

[Dives]

Model scaling. That is essential. UE3 does it so effortlessly. That would be the #1 most convenient thing they could add.

[Epifire]

Model scaling. That is essential. EU3 does it so effortlessly. That would be the #1 most convenient thing they could add.

Funny cause that is such a simple thing too but Valve never added that in. I guess they were to cool and thought scaling in the QC was just fine.

So excited to see the new features when ever they come out with it finally.

[serpent]

a few things already mentioned here but i really want to see:

- Auto Optimisation ( no need to make hints or anything, the VVIS stuff)
- Real time editing
- move to a sandbox style engine since all engines are this way these days, no needing to put everything into a box
- improved terrain system


the main two points id just love to see really is the sandbox and terrain system
with that in place the maps could be potentially huge!

[Gary]

Without VIS, sandbox editing should be easy. As you need to seal the map just so VIS can figure out what's inside the map and what can and can't be seen.

[Mr. Happy]

Sweet! Really need to delve into SFM, too many maps and models to make though.

The new hammer icons are pretty interesting . What features would people like to see in source2 ?

Agree with most everything everone has said except stoopdapoop. My understanding is that vistables are still very useful, since they are extremely fast. The only issue is that they can be difficult to build for. Unreal uses "precomputed visibilty volumes" for mobile games since they help so much. Would it not be fastest to run vvis and THEN use occlusion culling? What I think is really needed is better vvis algorithms to take the stress off the designer in optimizing the tree.

Tools I'd like to see:

* Simpler/easier leaftree construction

* CSG surface occlusion (CSG surfaces "casting" occlusion)

* CSG remaining as a geometry construction method (so easy!)
* * Planar brushes (single planes)
* * Ability to split volume brushes into planar brushes
* * Compound brushes (in-editor CSG) as an OPTION (not an editor defining methodology)
* * Once you have planar brushes, normal inversion is obvious (basically, all the sweet features of JupiterFX and UnrealEd and Hammer combined)
* * Re-triangulation of brushside plane definitions on exiting clipping tool/deselction of brush in vertex tool

* Bezier/CV/CP/Linear path creation and full reparameterization of path style entity chains

* in-editor object keyframing

* Assignable hot-keys

*Nodegraph editing of logic (see Kismet)
* * Right now logic is based on "impulses/signals", would like better ability to read states and/or automatically execute functions
* * A second visual interface for editing VScript

* More in-editor help, tool tips, and a learning path

* In-Game editor (could be annoying if programmers break game, because then tools break too) or in-editor game.

* Detatchable viewports and multi-monitor support

* Per-Game window layout saving

* Manifests, whatever those are

* Multiple definable pivots per-object

* Patch grids

* Displacement tools

Import/Export Free Art Pipeline
--------------------------------------
* Importing assets easily would be nice, having a hot-key in the 3D modelling app of choice to "send to Source" and a hotkey in Hammer to "send to App" would be betterish (probably need both to solve complex models)

* Need hotkey at all? Editing a PSD and saving it, then tabbing to Max/Maya/XSI makes, that just updates perfectly

* A deeper content management system in general

* Ability to send a brush into the 3D App for reference/collision

* Shape Grammar tools
* * Caves/surfaces with user editable sub-patches
* * Mesh extrusion: make a few rules and pieces and now you can "draw out" railings, tracks, etc.

* Multi-layer texture blending

* Deeper foilage system
* * Spray paint
* * Hand place
* * Rules (i.e. VBSP detail files)
* * Extract rules from hand edited pieces

Random & Minor
--------------------
*Grid color controls
*Choose program for FGD editing
*Larger selection handles and other applications of Fitts' law (scale handle as mouse moves towards handle?)

That's most everything off the top of my head...

[kraid]

As for content pipeline, i'd rather see a direct .fbx/.dae import for models and .tga/.psd for textures, with the possibility to do easy reimport of the original data in case of changes.

And another big thing: lightmapped models.

Also instead of these hacky methods like adding a command line to the launch options of a game to get access to the particle editor, it would be nice if this was integrated either in the editor, or at least in the SDK launcher.
Same for Material/Shader editor etc.

Anyway, we'll have to wait for valve to come up with something big... hopefully.

[stoopdapoop]

Agree with most everything everone has said except stoopdapoop. My understanding is that vistables are still very useful, since they are extremely fast. The only issue is that they can be difficult to build for. Unreal uses "precomputed visibilty volumes" for mobile games since they help so much. Would it not be fastest to run vvis and THEN use occlusion culling? What I think is really needed is better vvis algorithms to take the stress off the designer in optimizing the tree.

You're absolutely right about using BSP to figure out a PVS (potentially visible set, or precompted visibility volumes as unreal seems to call them) first, then using occlusion culling. I wasn't saying that they should dump PVS and BSP, it's still incredibly useful and as far as I know it's still the dominate way to handle spacial partitioning. I was saying they should dump VVIS, which is the name of valve's particular implementation. I'm guessing the first v stands for valve, so VVis is the valve visibility solver, and Vrad is the valve radiosity solver, and Vphysics is the valve physics solver, and so-on.

VVIS is dependent on brush geometry and it doesn't take model geometry into consideration at all, it's much too coarse where it needs to be fine, and it's much too fine where it needs to be coarse unless you take some very special care. Also it has no allowances for dynamic occluders at all, which is really painful.

And I could be wrong about this, but I Think Unreal uses BSP for to speed up entity searches and to very coarsely divide up the map into large volumes that can be portal tested against. So while it is technically creating PVS data, most of the actual occlusion is being done with portals and antiportals. Unlike source where most of the occlusion is done by the PVS alone, and occluders/portals are just used to supplement.

I think we agree more than we disagree on this issue.

somewhat related: umbra is pretty cool.

[Epifire]

- move to a sandbox style engine since all engines are this way these days, no needing to put everything into a box

Can't say I agree there. You see those, "boxes" help old computers run Valve games quite well on old computers. I would be disappointed to see Valve cave into the sandbox design since they already do so well without. I guess it is all opinion and speculation right now though, until we start seeing more.

[joe_rogers_11155]

A bloody trigger window, like those in Starcraft or Warcraft 3, instead of having 24 entities spread around the map for doing one thing, and to get a clue of what the hell is going on, you're going to have to open each of them.

this. I am sick and tired of flying across the map to open an entity, and trying to use the "camera" system is really annoying too because all of my cameras end up in one place anyways because i am constantly flying around building things here and there and everywhere. it becomes a huge mess if i try to use more than one camera.

here's some things I would love to see:
-trigger window (or some related user-friendly I/O construction method)
-drag-and-drop assets (unlikely I think)
-painting several textures onto a single brush and blending as though they are displacements
-more crash-resistant editor!!! no more crashing to desktop in the blink of an eye for no reason at all!!!
-simplification in the area of setting up the editor for a particular mod, and then switching from one mod to the other (I always have trouble in the area of setting up hammer to see and use new assets and new entities)