381:
little or nothing to do with whether one is using rasterization or ray tracing. Perhaps the sentences could be replaced with a mild claim that ray tracing can make more effective use of BSP-based culling, because the volume of interest can be a single ray, rather than the view frustrum. However, I feel that there is NO justification for talking about linear versus logarithmic performance. If I'm going on a long journey, I don't care if my car can instantaneously teleport itself to the end of my street; what I care about is the car's performance over the whole trip. It is technically useful to be aware that ray-tracing has a specific benefit in relation to BSP-tree culling. It is misleading to make a broad statement about performance. If this was an article about the performance benefits of BSP-tree culling, then the performance claim might be appropriate.
366:
anyone involved in a modern rasterizer-based engine, whether hardware or software, would take issue with that comparison. Hence, it is probably not NPOV. I do understand the point being made: the logarithmic solution for ray tracing comes readily; approaching logarithmic for rasterizers requires other complex techniques. And yes, the rasterization itself will still be linear. But, a "properly implemented" GPU based on rasterization will NOT display linear metrics for a scene of interesting complexity. And this is truer and truer every year.
160:
142:
317:"Whilst the complexity of the computation for rasterization scales linearly with number of triangles the complexity of a properly implemented ray tracing algorithm scales logarithmically; this is due to objects (triangles and collections of triangles) being placed into BSP trees or similar structures, and only being analyzed if a ray intersects with the bounding volume of the binary space partition."
22:
74:
53:
350:
the sense of needing to be applied to ALL polygons in the viewing frustrum) is per-pixel depth calculation. The EXPENSIVE operations (texture lookup, lighting) can, at least in theory, only be done for visible pixels of visible polygons. E.g. identical to what is claimed as one advantage of ray-tracing. IMHO, no longer a significant advantage for ray-tracing.
321:
IMHO this could mislead the reader, if taken as a comparison to the alternative hardware approach ( current mainstream GPUs, which are rasterization based). While rasterization itself does scale linearly, that isn't where the bulk of graphics time is spent in modern games (which are the leading edge
380:
Having pondered the issue some more, I now believe that the mentioned sentences should be DELETED. Consider a dynamically changing scene. Whether performance degrades towards linear has everything to do with the quality of one's culling approach (e.g. how quickly one can modify the BSP-tree) -- and
349:
I see that "Note 5" mentions that BSP can be used with rasterization, but only to reduce to the viewing frustrum. Again, true but misleading. That's what z-buffer helps with. Yes, the BSP only takes one so far, but combined with a z-buffer makes rasterization cheap: the only "linear" algorithm (in
365:
After further thought, I have marked the statement as POV, despite the notes that attempt to lessen its POV-ness. Reason: The paragraph compares the simplest possible implementation of rasterization, to "a properly implemented" ray tracer. This is not an apples to apples comparison. I think that
408:
As I noted before - newer API rasterisation methods such asDirectX 10 D3D10_QUERY_OCCLUSION_PREDICATE or OpenGL 3.0 HP_occlusion_query can help cull BSP volumes better than a simple frustrum cull (and better than linear)- especially if you add code to try to process the
346:
Bottom line: while the statement is true, in a narrow sense, it needs more context, to be helpful rather than misleading. I'm not sure I know enough to attempt to rewrite it, so for now I'll just comment on it, in hopes this inspires someone else to do
435:
this before deferred rendering was commonly implemented in commercial software (ie games) - nowadays it is almost a standard.. Subjectively it could be said that the the term "difficult" is no longer accurate.
243:
should be merged and redirect to this article - articles cover research projects, not final products - there is at least as much info in this article as there are in the separate articles on the specific
340:
mentioned as a benefit of ray tracing when compared to rasterization, since BSP trees are an essential part of all modern (rasterization based) game engines. As discussed in
413:
scene's BSP spaces in order roughly "near front to far back" order.. - works better on "inside" or "hilly" scenes and poorly on scenes with fractally structures eg trees..).
466:
124:
114:
471:
461:
481:
208:
90:
214:
476:
399:- you nailed it. I actually wrote this article several years ago, and have long since ceased editing, but happened across this old page by chance.
81:
58:
184:
436:
486:
167:
147:
269:
33:
397:
The paragraph compares the simplest possible implementation of rasterization, to "a properly implemented" ray tracer
341:
337:
386:
371:
355:
263:, because there aren't any citations yet. But I'm not sure about the other one, as it's a disambiguation page.
21:
440:
180:
382:
367:
351:
299:
249:
39:
295:
245:
291:
183:
on
Knowledge. If you would like to participate, please visit the project page, where you can join
89:
on
Knowledge. If you would like to participate, please visit the project page, where you can join
275:
86:
327:
331:
455:
264:
323:
444:
390:
375:
359:
303:
281:
253:
159:
141:
431:
It's possible that other parts may need altering, or modifying - eg I wrote
176:
172:
73:
52:
260:
236:
334:
for techniques that restrict the exposure to linear-scaled algorithms.
287:
240:
15:
422:
I plead out of date info, not an intention to mislead ;) ..
403:
402:
I take the point - and have removed the comparison. eg
328:
Deferred shading#Deferred lighting in commercial games
171:, a collaborative effort to improve the coverage of
85:, a collaborative effort to improve the coverage of
213:This article has not yet received a rating on the
294:page - didn't notice the link was to a disambig.
8:
19:
136:
47:
467:Low-importance computer graphics articles
259:I do agree with the merge, especially on
138:
99:Knowledge:WikiProject Computer graphics
49:
472:WikiProject Computer graphics articles
462:Start-Class computer graphics articles
102:Template:WikiProject Computer graphics
482:Unknown-importance Computing articles
342:BSP trees / Overview, final paragraph
7:
165:This article is within the scope of
79:This article is within the scope of
38:It is of interest to the following
14:
322:drivers of GPU performance). See
158:
140:
72:
51:
20:
193:Knowledge:WikiProject Computing
119:This article has been rated as
477:Start-Class Computing articles
196:Template:WikiProject Computing
1:
304:16:21, 27 February 2010 (UTC)
282:14:07, 27 February 2010 (UTC)
254:14:05, 27 February 2010 (UTC)
187:and see a list of open tasks.
93:and see a list of open tasks.
82:WikiProject Computer graphics
391:12:25, 23 October 2012 (UTC)
376:08:56, 23 October 2012 (UTC)
360:08:29, 23 October 2012 (UTC)
336:Also, its rather odd to see
312:Comparison to rasterization
503:
215:project's importance scale
125:project's importance scale
105:computer graphics articles
445:01:33, 31 July 2013 (UTC)
212:
153:
118:
67:
46:
433:"shadows are difficult "
487:All Computing articles
181:information technology
28:This article is rated
168:WikiProject Computing
292:Ray Processing Unit
199:Computing articles
34:content assessment
229:
228:
225:
224:
221:
220:
135:
134:
131:
130:
96:Computer graphics
87:computer graphics
59:Computer graphics
494:
278:
272:
267:
201:
200:
197:
194:
191:
162:
155:
154:
144:
137:
107:
106:
103:
100:
97:
76:
69:
68:
63:
55:
48:
31:
25:
24:
16:
502:
501:
497:
496:
495:
493:
492:
491:
452:
451:
332:Tiled rendering
314:
276:
270:
265:
234:
232:Proposed merges
198:
195:
192:
189:
188:
104:
101:
98:
95:
94:
61:
32:on Knowledge's
29:
12:
11:
5:
500:
498:
490:
489:
484:
479:
474:
469:
464:
454:
453:
450:
449:
448:
447:
426:
425:
424:
423:
417:
416:
415:
414:
406:
400:
383:ToolmakerSteve
378:
368:ToolmakerSteve
352:ToolmakerSteve
348:
345:
335:
319:
318:
313:
310:
309:
308:
307:
306:
233:
230:
227:
226:
223:
222:
219:
218:
211:
205:
204:
202:
185:the discussion
163:
151:
150:
145:
133:
132:
129:
128:
121:Low-importance
117:
111:
110:
108:
91:the discussion
77:
65:
64:
62:Low‑importance
56:
44:
43:
37:
26:
13:
10:
9:
6:
4:
3:
2:
499:
488:
485:
483:
480:
478:
475:
473:
470:
468:
465:
463:
460:
459:
457:
446:
442:
438:
437:83.100.174.82
434:
430:
429:
428:
427:
421:
420:
419:
418:
412:
407:
405:
401:
398:
394:
393:
392:
388:
384:
379:
377:
373:
369:
364:
363:
362:
361:
357:
353:
343:
339:
333:
329:
325:
316:
315:
311:
305:
301:
297:
293:
289:
285:
284:
283:
279:
273:
268:
262:
258:
257:
256:
255:
251:
247:
242:
238:
231:
216:
210:
207:
206:
203:
186:
182:
178:
174:
170:
169:
164:
161:
157:
156:
152:
149:
146:
143:
139:
126:
122:
116:
113:
112:
109:
92:
88:
84:
83:
78:
75:
71:
70:
66:
60:
57:
54:
50:
45:
41:
35:
27:
23:
18:
17:
432:
410:
396:
320:
290:I meant the
235:
166:
120:
80:
40:WikiProjects
324:Z-buffering
296:Shortfatlad
246:Shortfatlad
30:Start-class
456:Categories
338:BSP trees
190:Computing
177:computing
173:computers
148:Computing
411:object's
261:SaarCOR
237:SaarCOR
123:on the
330:, and
266:Minima
244:items.
179:, and
36:scale.
395:Yes.
347:so...
441:talk
404:diff
387:talk
372:talk
356:talk
300:talk
286:For
277:talk
250:talk
239:and
288:RPU
241:RPU
209:???
115:Low
458::
443:)
389:)
374:)
358:)
326:,
302:)
280:)
252:)
175:,
439:(
385:(
370:(
354:(
344:.
298:(
274:(
271:c
248:(
217:.
127:.
42::
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.
