Game Engine or custom game engine?

Started by
40 comments, last by JoeJ 5 years, 2 months ago
44 minutes ago, Samiorga said:

No mention of this whatsoever. They were a startup company so they were probably looking for someone young with a lot of programming experience. And they used lines of code as a reference to calculate the amount of experience that they had...

I suggest that they probably weren't expecting you to have *written* a million lines of code. I don't think anyone expects that of junior developers. The phrasing you used here is "how many lines experienced." I would assume that they were asking about whether you had worked in a codebase that large before. I suspect based on this that they already have a codebase that large and are looking for people who are comfortable working in those sorts of circumstances.

9 hours ago, Fulcrum.013 said:

For first mainstream engines failed to use a modern hardware abilities. for example it no engines around that support spline-based models, while it significantly improve quality, decreace size of models and have hardware support since DX11 has been introduced over 8 yers ago.

I suggest that if game artists wanted to deal with building, rigging, and animating spline-based models, and programmers wanted to deal with optimizing their rendering, then game engines would support them. Currently I don't believe that is the case. ;) 

Quality generally takes a back seat to performance and tools support in the video game industry. Remember, video games are magic shows. They don't have to look exactly accurate, they just have to look "not wrong." Many corners are cut in the name of performance.

Also, source on DX11 supporting splines-based rendering? I googled, but I can't find anything on this. DX11 does support tesselation, but that's not the same thing.

Advertisement

 

10 hours ago, Fulcrum.013 said:

For first mainstream engines failed to use a modern hardware abilities. for example it no engines around that support spline-based models, while it significantly improve quality, decreace size of models and have hardware support since DX11 has been introduced over 8 yers ago. And for main gaming != graphics only. It ever more of phisic simulation and game ai/logic than graphic

And for instance, Nurbs, Splines and so on were removed from modern OpenGL, certainly not due to hazard. You can have such surfaces, for sure. But in the editor. And it will create as usual triangles. GPUs are very well optimized for triangles. OpenGL also deprecated quads for example. Triangles are nice because triangles are plane eggs.

True, you can decrease the size of models thanks to surface control points. But not that much. Also, if you want to add other attributes except vertex position and normals (ie color, texture coordinates, TBN basis...), then this will become very harmful to play with at rendering time.

8 hours ago, _Silence_ said:

And for instance, Nurbs, Splines and so on were removed from modern OpenGL, certainly not due to hazard.

For instance GL and DX never support splines before. It has support outdated non-rational bezier patches only.  Modern GL and DX moved support of pathces from fixed pipeline part to programmable part (tesselation stage) since DX11 and GL 4.5. It extends splines support to about any type of spline.

8 hours ago, _Silence_ said:

Triangles are nice because triangles are plane eggs.

For instance triangle is a rookie (1st order ) spline. And it is main of triangle disadvabtages.

8 hours ago, _Silence_ said:

Also, if you want to add other attributes except vertex position and normals (ie color, texture coordinates, TBN basis...), then this will become very harmful to play with at rendering time.

For example accurate tangent and bitangent calculated by the way during computation of accurate normal, and it cheaper than transform it. So with splines you not just have less vertices, you just need position and  texture coords only as vertex attributes. 

 

10 hours ago, Oberon_Command said:

Also, source on DX11 supporting splines-based rendering? I googled, but I can't find anything on this. DX11 does support tesselation, but that's not the same thing.

Tesselation good for rational bezier patches. So any kind of splines that extends rational bezier splines can be rendered using offline pre-tasselation to rational beziers patches. By the way it also good fot many other algos (like subdivision surfaces for example) that utilize similar to spline concepts.

 

10 hours ago, Oberon_Command said:

I suggest that if game artists wanted to deal with building, rigging, and animating spline-based models,

Really it much intuitively and productively for design than triangles. Modern CADs already have much better tools than 3DMax etc at least for machinery and architecture, and about any non-natural object.  Of cource it require a engeenirs, not a artist to design models productively. For example how many time artist have spent to make models like it using a 3D Max or similar 3D-pinbrush?

2016009692_tunguskarear.thumb.JPG.8e773e563c9e8e90dd4481a3f4331f46.JPG1722841779_.thumb.JPG.bf58c2362ca350949ef9d0486b9356d8.JPG1406487617_.thumb.JPG.089ad2bd13998438e2472d0ca45f49a5.JPG

I has spend no more than one day for actual modeling of pistol and submachine gun and couple days for turret. But im not a 3D atrist at all and not a weaponery engeener. Im just little bit experienced with CADs. Also models good for modern lowpoly demands ever after default pre-tesselation to trangles. For example submachine  have ~24k vertices and ~24k triangles that is ok for top LOD. In spline representation it have less than 4k vertices that can be tesselated adaptively to have any LOD. Also removal of expensive holes and so on for making a low-level LODs is very simple operation for CAD  that performed by single click, unlike 3D pinbrushes Max.

10 hours ago, Oberon_Command said:

and programmers wanted to deal with optimizing their rendering

Splines have many optimizations embedded directly to mathematical core. For example ability to optimal tesselation in dependence from surface curvature and so on.

#define if(a) if((a) && rand()%100)

9 hours ago, _Silence_ said:

And for instance, Nurbs, Splines and so on were removed from modern OpenGL, certainly not due to hazard.

At GeForce3 times i utilized bezier patches a lot, and after they have removed their hardware support i complained to NV and Mark Kilgard himself replied: "Nobody used them" :) 

At this time i was not aware the non-rational limitation made them useless anyways, @Fulcrum.013 pointed this out to me recently.

I agree with him about the fact that games ignore any alternative geometry, which is a missed opportunity. Irregular triangle meshes are not the most efficient thing - the have no LOD built in. I mean there is a lot about tiny voxels, or SDF, but restrictions to fixed world grids and huge memory requirements turns this mostly into a waste of time IMO.

Nurbs, converted to simple patches are quite interesting, not only for human made stuff. They have built in parametrization and so allow for seamless displacement mapping (e.g. landscape with overhangs and tunnels with little storage). The resolution of the parametrization however is not uniform, this is something quadrangulation aims to solve at the cost of less control over details. (I work on this - it's a torture, but i'm finally done, almost :) ) 

All this is very interesting but underutilized in games yet.

Just to clarify, the primary reason that game developers don't use spline or patch based meshes at runtime is that the throughput on GPU is relatively poor. In most cases the GPUs are much better at pushing triangles than trying to do adaptive detail tessellation, as there are challenges across different hardware with how much expansion is actually viable and how on-chip buffers for tessellation outputs get sized. It can be more useful to use compute shaders to expand the tessellation ahead of time, but it's not really that helpful at the end of the day for most of the models we actually want in a game.

Please don't take Fulcrum's ignorance as representative of where game developers are at technically. In general, I would put runtime polygonal detail levels waaaay down the list of challenges graphics programmers should be spending their time on. It wouldn't even be close to making my top ten.

SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.
22 minutes ago, JoeJ said:

At this time i was not aware the non-rational limitation made them useless anyways, @Fulcrum.013 pointed this out to me recently.

Non-rational disallow to match spline with quadrics, so make a big head-pain  with modelling of spheres, cylinders, cones, and other quadrics forms from wich human prefer to make his machines and other products. 

#define if(a) if((a) && rand()%100)

3 minutes ago, Promit said:

ust to clarify, the primary reason that game developers don't use spline or patch based meshes at runtime is that the throughput on GPU is relatively poor. In most cases the GPUs are much better at pushing triangles than trying to do adaptive detail tessellation, as there are challenges across different hardware with how much expansion is actually viable and how on-chip buffers for tessellation outputs get sized. It can be more useful to use compute shaders to expand the tessellation ahead of time, but it's not really that helpful at the end of the day for most of the models we actually want in a game.

I agree with this and do not aim to use tesselation shaders. My motivation comes from a completely different direction: The need for global parametrization for GI with surface caching. I came across ideas to use this stuff for visible geometry as well only unintentionally, and i'm not sure yet if really works well (speaking of quadrangulation). I assume it works for most visible geometry, and it opens new possibilities to solve the LOD problem.

Graphics is about two things: Visibility and LOD. There is very little progress in games here. And in this context...

9 minutes ago, Promit said:

Please don't take Fulcrum's ignorance as representative of where game developers are at technically.

... such a comment gives me doubts who is ignorant here, in all respect. Our aim is to progress state of the art, not to stick at it forever.

Any discussion of ideas here, any showings of results should be welcomed i think.

It may be practicable now, it may not, it may need more work... but in the end it might turnout useful.

Personally i try to get there without any change on the workflow of artists, other than reducing their need to work on manual LODs.

Fulcrum pointed out CAD modeling is faster for many kinds of objects, which surely isn't wrong either.

 

16 minutes ago, JoeJ said:

.. such a comment gives me doubts who is ignorant here

A minute later i feel sorry. Surely you only want to put things in perspective, which i agree is necessary.

It's just i get triggered quickly because i often run against walls what talking about alternative ideas. ;)

24 minutes ago, Promit said:

In most cases the GPUs are much better at pushing triangles than trying to do adaptive detail tessellation, as there are challenges across different hardware with how much expansion is actually viable

Nobody has promised that it simplier to implement then triangles. Especially in current 2-stage tesselation architecture (on initial de Casteljau algo number of subdivisions determined on vertex position computation stage ). And also splines and other curved surfaces much better and efficient for ray-trasing (that is realy next gen of game realism)  then triangles. All CADs have a ray-traced renders for photo-realistic image generation.

#define if(a) if((a) && rand()%100)

This topic is closed to new replies.

Advertisement